The problem
We need to run Executor as a production service on AWS ECS/Fargate.
The current Docker self-host model keeps durable application data in a local SQLite/libSQL database under /data . That works on a long-lived Docker host, but it does not have a supported persistence model for a managed container service:
• Fargate task-local storage is lost when a task is replaced.
• We considered mounting /data from EFS so data survives task replacement, but EFS is an NFS network filesystem.
• Executor uses SQLite WAL mode, and SQLite does not support WAL databases on network filesystems.
• Restricting the service to one task and preventing deployment overlap reduces the chance of concurrent access, but does not make SQLite/WAL on EFS a supported production architecture.
This leaves us without a supported way to retain Executor data across Fargate task replacement while using the published Docker self-host image.
Proposed shape
Please support a remote libSQL database for Docker self-hosting through explicit configuration such as:
EXECUTOR_DB_URL=...
EXECUTOR_DB_AUTH_TOKEN=...
This should allow operators to place durable Executor data in a supported client/server database rather than mounting the active SQLite/WAL database from shared storage.
Please document:
• supported remote database providers and connection requirements;
• migration and first-start behavior;
• required externally managed secrets;
• graceful shutdown expectations; and
• the supported single-instance deployment model and its operational limits.
This is not an AWS-specific request. The goal is a platform-neutral Docker self-hosting model that supports normal container replacement and upgrades on ECS, Kubernetes, and similar schedulers.
Safe multi-replica interactive MCP operation is not required for this initial feature. If multiple replicas are unsupported, documenting that boundary would be valuable and can remain separate future work.
Alternatives
We considered EFS-backed /data storage, but rejected it because SQLite WAL is unsupported on a network filesystem.
Running Executor on EC2 with a local EBS volume would provide local filesystem semantics, but adds host and volume lifecycle management and does not provide a scheduler-friendly Docker deployment model.
Maintaining a private fork with remote database changes, or moving to another hosting platform, changes the support and infrastructure boundaries.
Where it belongs
Self-host (Docker)
Before you submit
The problem
We need to run Executor as a production service on AWS ECS/Fargate.
The current Docker self-host model keeps durable application data in a local SQLite/libSQL database under /data . That works on a long-lived Docker host, but it does not have a supported persistence model for a managed container service:
• Fargate task-local storage is lost when a task is replaced.
• We considered mounting /data from EFS so data survives task replacement, but EFS is an NFS network filesystem.
• Executor uses SQLite WAL mode, and SQLite does not support WAL databases on network filesystems.
• Restricting the service to one task and preventing deployment overlap reduces the chance of concurrent access, but does not make SQLite/WAL on EFS a supported production architecture.
This leaves us without a supported way to retain Executor data across Fargate task replacement while using the published Docker self-host image.
Proposed shape
Please support a remote libSQL database for Docker self-hosting through explicit configuration such as:
EXECUTOR_DB_URL=...
EXECUTOR_DB_AUTH_TOKEN=...
This should allow operators to place durable Executor data in a supported client/server database rather than mounting the active SQLite/WAL database from shared storage.
Please document:
• supported remote database providers and connection requirements;
• migration and first-start behavior;
• required externally managed secrets;
• graceful shutdown expectations; and
• the supported single-instance deployment model and its operational limits.
This is not an AWS-specific request. The goal is a platform-neutral Docker self-hosting model that supports normal container replacement and upgrades on ECS, Kubernetes, and similar schedulers.
Safe multi-replica interactive MCP operation is not required for this initial feature. If multiple replicas are unsupported, documenting that boundary would be valuable and can remain separate future work.
Alternatives
We considered EFS-backed /data storage, but rejected it because SQLite WAL is unsupported on a network filesystem.
Running Executor on EC2 with a local EBS volume would provide local filesystem semantics, but adds host and volume lifecycle management and does not provide a scheduler-friendly Docker deployment model.
Maintaining a private fork with remote database changes, or moving to another hosting platform, changes the support and infrastructure boundaries.
Where it belongs
Self-host (Docker)
Before you submit