ShippedDocker hosting
on Shipped.
When your application needs a particular runtime or system package, bring it in a container. Shipped runs the app and connects the services around it.
Make the application environment explicit
A Dockerfile defines how the application and its dependencies become a deployable image. Include the runtime, system libraries, and production entry point your project needs. Shipped supports containerized services so your stack choice does not have to fit a narrow list of application templates.
Separate the image from persistent data
Treat the container as the application release, not the permanent home for customer records or uploads. Connect a database and object storage for data that must survive replacement. Supply secrets at deployment time rather than baking them into image layers or leaving private files in the build context.
Deploy each workload for its purpose
Run an HTTP application as a web service, a queue consumer as a worker, and recurring commands as scheduled jobs. Your agent can ship source through MCP without requiring a GitHub push. Keep releases in deployment history so returning to an earlier app image is a deliberate operation.
A little more detail
Questions about Docker?
Does container hosting mean my Docker Compose file becomes a platform automatically?
A Compose project describes multiple local services. Map its web processes, workers, databases, storage, and configuration to the corresponding deployed resources; do not assume a one-to-one import without reviewing those needs.
Do files written inside a running container survive deployment?
Do not rely on the container filesystem for durable customer data. Use persistent storage and databases for anything that must survive replacement of the running application.
From your workspace to the web