Skip to main content

Deploy Docker Apps (Kit and Pro Plan)

Docker in DOM Cloud is powered by Docker rootless mode. Enabling docker features is implicitly allows running 24/7 (doesn't have to actually using docker). Because of how powerful and resouce consuming this is only available with Kit and Pro user plan.

We recommend to use this feature only in Tier I servers (SGA and NYC) as they offer the most computing resources we currently offer

When this feature enabled, these things applied:

  • assign /etc/subuid + /etc/subgid to allow docker using sub uids for assigning containers.
  • assign /var/lib/systemd/linger to allow backround processes not get killed when SSH session terminates.
  • registering dockerd as user-scoped systemd daemon by and set it to run at startup.

Port Allocation Policy

A docker service should run all the time and have a standby port hidden from the internet.

Remember that DOM Cloud servers is a shared hosting environment, so only expose your port only for public-facing service. A port between 9000 and 32000 is a recommended port number. A port number 32768 and above is not recommended as it's an ephemeral ports only for internal/test usage (firewall don't block incoming traffic for them).

We'll choose this number for you by random for use through the documentation: 17549


The deployment script below activates docker capabilities and starts a "hello world" container for demo.
source: clear
- docker
enabled: 'on'
app_start_command: 'socat TCP-LISTEN:$PORT,fork TCP:localhost:17549'
- docker run -t --name webserver -p 17549:80

Let's examine the reason why we use docker run commands as such:

  • Using run will create and start a new container pulled from
  • We're forwarding from host's port with number 17549 to container's port with number 80. This port number is permanent.
  • The 80 from -p $PORT:80 implies that the app ( is listening on port 80 inside the container.
  • --name webserver denotes the name of this container is webserver for easy debugging when inspecting via SSH later.
  • socat is used as port forwarder from $PORT given from passenger phusion to 17549 which your docker

Example with Docker Compose

To use docker-compose.yml, you can to run it via docker compose.

The example below setup Plausible self-hosting with their database depedencies.
# Requires Kit plan or higher!
- docker
root: public_html/public
enabled: 'on'
app_start_command: 'socat TCP-LISTEN:$PORT,fork TCP:localhost:17549'
- get_hash() { openssl rand -base64 64 | tr -d '\n'; }
- sed -i 's/8000:8000/17549:8000/g' docker-compose.yml
- echo BASE_URL=https://$DOMAIN > plausible-conf.env
- echo SECRET_KEY_BASE=`get_hash` >> plausible-conf.env
- docker compose up -d

Managing systemd daemon

Your docker instance is registered as user-scoped systemd service. You can call these systemd commands to diagnose docker problems

  • systemctl status docker --user
  • systemctl <start|stop|enable|disable> docker --user


Using docker has benefit compared other deployment system. These includes:

Allow additional background services

Adding entries to /var/lib/systemd/linger will make sure that your processes won't get killed anytime you log out from SSH session. This also means you can add custom database system (like MongoDB and Redis) simply by pulling and starting the database service with detached mode (or using docker's compose).

Note that with this benefit limitations by Fair Usage still implies. We won't restrict your CPU and RAM limits but still watching overall system performance and deliberately kills it if it proven to abuse our resources. Additionally, there should be no public port exposed to the host other than what's given from passenger's $PORT to avoid depleting server's ports allocations.

Allow building apps by Continous Integration (CI)

While other deployment system is benefited by simpler DX (you can code and fix bugs directly in production) and incremental builds, there are often a reasonable choices to use CI to build apps and only deliver the binary to us via docker images.

One of the benefit is you will be able to version your binaries via CI artifacts, this including releasing binaries via code versioning. This also added more security by not exposing your valuable source code to us, and lesser computation and storage used for compiling binaries by delegating it to CI instead of from our server.

... (example deployment code)