Standard Docker builds
Multi-stage builds, build arguments and private base images work as they do in your own CI.
/docker-hosting.html
Docker hosting
If it builds locally, it deploys here. Bring your own image definition and let the platform handle registry, placement, TLS, health checks, restarts and rollbacks.
Dockerfile builds · multi-stage · private base images · persistent volumes · isolated containers
Multi-stage builds, build arguments and private base images work as they do in your own CI.
Every service runs in its own container with its own resource boundaries; dedicated plans do not share CPU with other tenants.
Attach a persistent disk where your container needs state that must outlive a deploy.
Failing health checks stop a bad release from taking over, and crashed containers are restarted automatically.
Private networking between your own services is in beta — useful for an API and worker pair that should not go via the public internet.
Container workloads that serve media or large API responses are not metered per gigabyte.
Containers are billed as the box they run on, not per image or per build. Multi-service applications are several plans; agencies and larger architectures are quoted directly.
See all plans and what is included →The Dockerfile is detected; set a different path or build context if needed.
dockerfile: ./docker/Dockerfile
Expose the port your process listens on and the platform routes to it.
EXPOSE 8080
A health endpoint lets deploys verify themselves before taking traffic.
healthcheck: GET /health
Building from your repository is the supported path today. If you need to deploy an image from your own registry, ask us — it is handled case by case.
More operational detail is on the full FAQ page.
If your Dockerfile builds on your machine, it will build here. Try it on a test service before moving production.
Keep your existing service online while you evaluate DebutDeploy.