Docker Compose

Early access. Docker Compose is open to invited accounts while we test it. Ask the Raklane team for an invite; until then, Docker Compose doesn't appear in your project.

If your project already runs with docker compose up, a Laravel app with MySQL and Redis for example, Raklane can deploy the same Compose file as a stack. Every service becomes an app or a database of your project. The services deploy together and keep reaching each other by their Compose names, so DB_HOST=mysql and REDIS_HOST=redis work unchanged.

Deploying a Compose file

1. Open your Project and choose Docker Compose → Deploy Docker Compose.
2. Source. Enter the repository and branch. For a private repository, pick the access token or SSH key from your Secrets. Raklane finds compose.yaml or docker-compose.yml at the root; set another path if yours lives elsewhere.
3. Services. Raklane reads the file and shows what each service will become, with anything it can't apply. Here you can:
   • switch a service between an app and a data service
   • turn a public URL on or off
   • pick a secret for each build secret the Compose file uses
4. Deploy. Name the stack, choose where it runs, and choose the size its databases get.

Databases start first. Then the apps deploy in depends_on order, each once what it depends on is up. All of them build from the same commit.

What each service becomes

Raklane looks at what a service is, not only at how your Compose file gets it. A build: service whose Dockerfile starts FROM mysql:9.7 (plus a config file, say) becomes a managed MySQL 9.7. One that starts FROM redis becomes a Redis data service. Raklane shows a warning that the Dockerfile's own steps aren't applied. A service that keeps its data in /var/lib/mysql, or sets MYSQL_ROOT_PASSWORD, is recognised the same way. If Raklane guesses wrong, pick what it runs as in the Services step.

A few more Compose settings carry over:

• Ports.
  • The first published ports: entry gives the app a public URL.
  • A service that only expose:s a port is private: only the project's other services reach it.
  • A service with no port, such as a queue worker, just runs.
• environment and env_file become the app's environment variables. ${VAR} values come from the repository's own .env.
• command and entrypoint become the app's start command.
• A healthcheck that requests a URL becomes the app's HTTP health check. A data service's healthcheck runs inside it.

Database passwords. A managed database generates its own user and password. Wherever an app's environment uses the user, password or database name your Compose file gave the database, including inside a connection URL like mysql://laravel:secret@mysql/laravel, Raklane puts the real ones in. You don't edit your .env.

Not carried over. These are listed as warnings before you deploy:

• privileged, cap_add, devices, network_mode and user
• bind mounts, and volumes on apps (apps are stateless: keep data in a database or a data service)
• runtime secrets (set them as environment variables instead)

The stack page

The stack page shows every service as a graph. Solid arrows come from depends_on. Dashed ones are connections Raklane found itself: another service's name used as a host in a service's environment (DB_HOST=db), or in a config file its Dockerfile copies in (fastcgi_pass app:9000). Hover an arrow to see where it was found. Both kinds set the deploy order, so db is up before the app that uses it. Each service shows its status, and links to its own app or database page, where logs, metrics, backups and settings are as usual. From the stack page you can:

• Redeploy: deploy every app again at the branch's latest commit.
• Sync from Compose: see what changed in the Compose file (services added or removed, a new image, new environment variables), then apply it.
  • A data service with a new image is backed up first, and rolled back automatically if the new version doesn't come up. For example, Redis can't go back to an older version that can't read its data.
  • A removed service keeps running on its own unless you tick it for deletion.
• Auto deploy: with it on, a push to the branch syncs and deploys the whole stack once, not once per app.
• Delete: deletes the apps. Databases stay in the project unless you choose to delete them too.

Good to know

• A stack runs on one server, so its services can reach each other by name.
• include and dockerfile_inline aren't supported, and a file outside the repository can't be referenced.
• Variables you remove from the Compose file stay on the app until you delete them there.