Deploy a Docker Compose Stack on Temps
Temps deploys a docker-compose.yml, docker-compose.yaml, compose.yml or compose.yaml file directly with its Docker Compose preset: it builds the services that have a build: section, runs docker compose up for each environment, and routes the services that publish a port through its proxy. Use it when your app is more than one container, for example a web service plus a worker, or when you want a service to keep data in a named volume. A single-container app is simpler as a Dockerfile or image deploy.
Create the project
- Go to Projects → New Project and pick the repository that contains your Compose file.
- Temps detects the Compose file and selects the Docker Compose preset. A Compose file takes priority over a
Dockerfileor a framework in the same directory; pick another preset if you'd rather deploy those. - Temps lists the services in the file. Exclude any you don't want it to run, typically a database you'd rather run as a Temps managed service with backups.
- Add your environment variables and deploy.
For a project without a Git repository, you can paste the Compose file into the project instead.
What happens on deploy
- Temps checks out the commit and validates the Compose file against its security policy.
- It builds every service that has a
build:section and pulls the images of the others. - It runs
docker compose upin a Compose project of its own for each environment, so production and preview stacks don't share containers. - It waits up to 5 minutes for every service to be running, and healthy if the service defines a
healthcheck. A service that crashes or never becomes healthy fails the deployment. - It records every container of the stack against the deployment, not just one.
Environment variables
The project's environment variables, together with the variables Temps adds itself (such as TEMPS_API_URL and TEMPS_API_TOKEN), are written to a generated env file and injected into every service. A .env file in your repository is kept as it is.
Temps does not set PORT for Compose projects. Each service listens on the port your Compose file gives it. See Manage environment variables for the full list of variables Temps injects.
Ports and domains
- A service that publishes a port (
ports:) is reachable through the Temps proxy on the project's URL and domains. - A service without published ports stays on the internal network. Use this for workers, queues and internal APIs.
- When several services publish ports, point each custom domain at the service it should reach: the domain form has a Compose Service field. A domain with no service set routes to all of them.
Databases and volumes
Every service joins the same Docker network as Temps' managed services, so a stack can use a Temps managed PostgreSQL, MariaDB, Redis or MongoDB service. Link the service to the project and read its connection variables (for example POSTGRES_URL or REDIS_URL) in your services.
To keep data on disk, use a named volume in the Compose file. Named volumes survive redeploys. Temps does not back them up: a database you run inside the stack is your responsibility to back up, which is the main reason to exclude it and use a managed service instead. See Backups for what Temps backs up.
Bind mounts and other host paths must stay inside the repository checkout; paths that point elsewhere on the server are rejected.
What a Compose file can't do
The Compose file runs on the same server as Temps, so Temps rejects the settings that would let a service reach the host. A deployment fails before anything starts if a service uses any of these:
| Rejected | Why |
|---|---|
privileged, cap_add, security_opt, runtime, use_api_socket | Would bypass the container sandbox or expose the Docker API |
devices, device_cgroup_rules, gpus | Host device and GPU access |
network_mode, pid, ipc, cgroup, uts or userns_mode set to the host | Host namespaces |
volumes_from, extends, a top-level include: | Pull in configuration or volumes from outside the file |
sysctls, group_add, cgroup_parent, oom_kill_disable, ulimits, tmpfs | Kernel and resource settings that can affect the whole host |
| External networks | Bypass the network Temps manages |
If you need to change a service only on Temps, add an override in the project's Docker Compose settings rather than editing the file in your repository. Temps checks the override before it uses it.
Redeploys
On every redeploy Temps stops the previous stack, keeping its named volumes, and then starts the new one. Unlike a single-container deployment, which keeps the old container serving until the new one passes its health check, a Compose stack is briefly unavailable while it restarts. Plan deploys of user-facing Compose stacks accordingly.