Hosting Docker Compose. Twój compose, nasz serwer.

1. Docker as an application type, not an add-on

Many hosting providers treat Docker as a feature reserved for more expensive VPS or cloud plans because it requires more isolation and control than typical shared hosting. On Saplo, Docker is simply one of the application types in the catalog, as readily available as WordPress or a static site, with no separate price premium just for running containers.

In practice, 152 of the 166 applications in the Saplo catalog use Docker under the hood, so the container engine runs on every Docker-enabled Box, regardless of whether you install a ready-made preset from the catalog or build your own custom image.

For your own Docker image, the custom application type lets you provide your own Dockerfile or docker-compose, without being limited to the ready-made recipes in the catalog, giving you full flexibility for non-standard projects.

2. Private image registry included

The application catalog also includes Docker Registry, a private image registry using the official registry:2 image. It comes with a simple UI for browsing repositories, tags, and layers in your browser, secured with basic authentication using a login and password generated randomly during installation.

For a team building its own images in CI/CD, this means you can store private images without a Docker Hub account and without the pull rate limits that free public registry accounts impose during frequent image pulls.

The registry UI acts as a reverse proxy to the API of the same registry under a single domain and without CORS. This means docker login, push, and pull work directly through the application domain, with no additional ports to configure.

3. How much RAM do Docker applications need?

Typical Docker applications in the Saplo catalog require at least 1 to 2 GB of RAM (Baserow, Chatwoot, Flowise, n8n, Windmill, and Typebot each require 1 to 2 GB), because an official image container usually includes more dependencies than a lightweight PHP installation or a simple static application.

Box M (2 GB RAM) can comfortably run one typical Docker application, while Box L (6 GB RAM) can run several Docker applications in parallel. When building a larger toolkit with a CRM, chat, and automation tools together, this is a practical minimum to prevent them from competing for memory. For an even larger set of Docker applications, consider Box XL, where 12 GB of RAM provides practical headroom for further expansion without having to check frequently which application is using the most memory on a given Box.

For your own custom Docker images, RAM requirements depend on what the image actually does, so check memory usage locally before choosing a Box, just as you would with any other container deployment.

4. Docker on Saplo vs Docker on a bare VPS

On a bare VPS, you have to install Docker yourself, configure the firewall for the container ports, and manually set up an SSL reverse proxy for every service you run. For anyone unfamiliar with Linux administration, this is a real barrier to getting started.

On Saplo, the LXC container on your Box already has Docker support configured, including keyctl and nesting. This means docker run and docker compose up work as soon as you log in over SSH, while the panel configures the reverse proxy and SSL for publicly accessible applications when you connect a domain.

With comparable resources, the price difference between a bare VPS and a Box with Docker is usually small, but the time needed to launch your first service is significantly shorter on Saplo because you don't have to configure the container engine from scratch.

5. Who it is for

For a developer who wants to deploy their own Docker image without setting up a VPS from scratch, the custom application type on Box M or L provides a ready-to-use Docker environment and automatic SSL for a connected domain.

For a team building its own images in CI/CD, the private Docker Registry in the application catalog eliminates the need for a public registry account and its pull rate limits.

If you want to test several Docker applications from the catalog at once, such as a CRM, chat, and automation tools, Box L with 6 GB of RAM gives you enough room to run several in parallel without competing for memory.

6. Deploying your first custom Docker image on Saplo

After selecting the custom application type, log in via SSH (available from Box M) and prepare a docker-compose.yml or Dockerfile for your project, just as you would in any other environment with Docker installed.

Configure the reverse proxy and SSL for a publicly accessible service through the Saplo panel after connecting your domain. Enter the port your container listens on, with no manual nginx or certificate configuration on your end.

Configure data volumes so that application data survives container restarts and is covered by your Box backup, if your plan includes backups.

For multi-container applications, such as a database, application, and worker in a single docker-compose, check whether the combined RAM requirements of all containers fit within the memory limit of your chosen Box before launching the entire stack.

The private Docker Registry in the app catalog lets you store your own built images and pull them onto your Box under the same domain using docker pull, without needing an account on a public registry.

7. CI/CD and automatic Docker image builds

A typical CI/CD workflow involves building an image in an external system (GitHub Actions, GitLab CI), pushing it to a private Docker Registry on Saplo, then running docker pull and restarting the container on your production Box.

You can automate the final step, pulling and restarting the container after a new image, with a simple script run over SSH or a webhook that triggers a workflow in n8n running on the same Box.

A private image registry eliminates the pull rate limits imposed on free public registry accounts. When you deploy several times a day, this can be a real problem if your external provider account does not include a paid plan.

For teams working across multiple environments (staging and production), you can use separate image tags in the same private registry. This makes it easier to control which application version runs in each environment.

8. Best practices for custom Docker images in production

Pin the base image to a specific version (e.g., node:20.11-alpine, not node:latest). This prevents a publisher's base image update from unexpectedly changing your application's behavior after the next container rebuild, often without any clear notice of the change.

A multi-stage build keeps the final production image small by excluding build tools and development dependencies. It speeds up image transfers to the registry and from the registry to the production server, and reduces the container's attack surface.

Environment variables and secrets (passwords, API keys) should never be entered directly into a Dockerfile as part of a Docker image. They should instead be passed at container runtime, because an image built with a secret inside may end up in a registry and be pulled from there by someone with access to it.

A healthcheck configured in the image or docker-compose automatically detects when the container is running but the application inside has stopped responding, for example, because a process has hung. Without a healthcheck, this can go unnoticed because the container itself technically keeps running.

Route container logs to standard output and standard error (stdout/stderr), not to files inside the container. File-based logs disappear with the container when it is removed, while stdout and stderr logs are easier to collect and review using standard Docker tools.

Regularly review which images and tags in the private registry are still in use to stay organized and free up disk space occupied by old, unnecessary image versions left behind by successive CI/CD deployments.

9. The Docker Hub ecosystem and community images as a starting point

A huge number of ready-made, official Docker images are publicly available (databases, application servers, supporting tools). This means most common services can be deployed on Saplo without writing your own Dockerfile from scratch, using proven, actively maintained images.

The Saplo application catalog includes ready-made configurations based on many such official images (e.g. prestashop/prestashop, n8nio/n8n, flowiseai/flowise). This means you do not even need to know that a given application runs in Docker, because the entire configuration is already prepared for you.

For custom requirements (custom application type), access to the full Docker Hub ecosystem and other public image registries lets you use ready-made images as a starting point and tailor them to your needs with your own Dockerfile built on top of the base image.

The private Docker Registry in the Saplo app catalog complements this ecosystem by giving you a place to store your own built images without publishing them publicly on Docker Hub. This can be an important security requirement for commercial, closed-source projects.

For technical teams tracking the evolution of the container ecosystem, including new orchestration tools and image-building practices, full SSH access to an LXC container with Docker support on Saplo imposes no restrictions compared with what is possible on a traditional, self-managed server with Docker.

10. Testing Docker images before production deployment

Test a new Docker image locally or in a temporary container on the same Box before it replaces a live production container. A bug in the new image, such as an incompatible dependency version, could make the service unavailable until the change is rolled back.

Tag images in the private registry with a specific version rather than only latest. This makes it easy to roll back to the previous working image if the new version causes problems after deployment to the production container.

For multi-container applications, such as docker-compose setups with a database, application, and worker, test the entire change as a complete set, not just one modified container. Version mismatches between connected containers often cause problems that do not appear when testing components individually in isolation.

A healthcheck configured in the image helps automatically detect when a new container is not working properly after deployment. Combined with a simple rollback script that restores the previous image tag, this lets you quickly revert a problematic change without a long service interruption. Although this simple testing and rollback setup is not a full CI/CD system, it significantly reduces the risk of lengthy downtime caused by a single, poorly tested deployment of a new image.

11. Summary: Docker as a standard feature, not a premium feature

Making Docker a standard infrastructure component available on every Box, rather than a feature reserved for the most expensive plans, reflects how widespread this approach to packaging applications has become in recent years. Whether you choose a ready-made recipe from the catalog or deploy your own custom image using the custom application type, the container engine is already configured and ready to use from day one on your Box. For technical teams accustomed to working with Docker on their own development machines, moving to Saplo requires no change in habits, only moving the same familiar workflow to a production environment with built-in domain and SSL certificate support.