Prepare your Docker app for a secure environment.
Vendor-neutral service definitions for images and Dockerfile-based applications.
What matters for your application
Repeatable builds
Use multi-stage builds, pin dependencies and keep secrets out of image layers.
Least privilege
Non-root users, enforced resource limits and private networks are production provider requirements.
Separate control and workload planes
Customer images never execute on this host. The development provider only simulates lifecycle states.
Where it fits
Package your application and its dependencies in one image. Docker gives teams using different runtimes a shared release format; it does not remove every operational responsibility.
- Backends with custom system dependencies
- Teams working across several languages
- Applications using the same image across environments
Its place in your application
The image contains application files. Persistent data, secrets and network access are managed separately. Restarting a container should not lose application data or queued work.
Before you begin
Choose services around the actual needs of your application. Include these points in your development and release plan.
- Use multi-stage builds to keep only runtime files.
- Keep .env files, private keys and database passwords out of image layers.
- Plan non-root execution, resource limits and health checks.
Common questions
Can I run my image on this server?
No. Customer containers are not executed on the control-plane server. Actual container execution will open only after a separate, isolated workload environment is ready.
Can I provision a live resource now?
Not yet. New registration and customer allocation are closed on the live site. Product guides are published; local development simulation does not create real services.