Skip to content

Currently in development — early access opening soon

Your Compose file, running like a real platform.

ComposeHost takes the Docker Compose stack you already have and runs it as a managed deployment — persistent volumes, private networking, automatic HTTPS, backups and logs — on infrastructure you never administer.

No Kubernetes. No VPS babysitting. No per-service billing.

Join early accessSee how it works
deployment map — project: atlas4 services healthy
docker-compose.ymlyou write this
services:
  web:
    image: ghcr.io/atlas/web
    ports: ["3000"]
    depends_on: [postgres, redis]

  worker:
    image: ghcr.io/atlas/web
    command: ./worker

  postgres:
    image: postgres:17
    volumes: [database:/var/lib/…]

  redis:
    image: redis:8

volumes:
  database: # persisted & backed up
app.atlas.devTLS auto
private network

web

:3000 · ×2

worker

always-on

postgres

volume: database

redis

internal only

volumes
backups
logs & metrics
compose filemanaged servicesprivate networkpersistent storagelogs & backups

The problem

Your Compose file is not the problem. The server is.

Defining the stack is the easy part — you did that ages ago. The drag is everything around it: the machine, the proxy, the certs, the disks, the 3 a.m. restarts. That's not application work. It's a second job.

Running it yourself means

  • Provisioning and right-sizing a VPS
  • Reverse proxy and routing config
  • TLS certificates, issuance and renewal
  • Firewall rules and open-port hygiene
  • Secrets living in .env files on the box
  • Backups you set up once and never tested
  • Disk filling up because Postgres grew
  • Dead containers nobody restarted
  • Uptime checks wired to your phone
  • Deploys over SSH and crossed fingers
  • Node failures with no failover story
  • Scaling anything means a bigger box

ComposeHost is the operational layer

Your Compose services run on managed infrastructure. Everything between docker compose up and a healthy production deployment is handled for you.

  • Managed routing, domains and TLS
  • Scheduled, tested volume backups
  • Health checks with automatic restarts
  • Per-service logs, metrics and alerts
  • Encrypted secrets, injected at runtime
  • Room to scale stateless services beyond one box

You keep the Compose file. You lose the pager.

How it works

Compose in. Managed deployment out.

Four steps, no control-plane YAML, no servers to prepare. If it runs with docker compose up, it's a deployment candidate.

  1. 01

    Bring your stack

    A published image, a repo with a Dockerfile, or the docker-compose.yml you already run. No rewrites, no proprietary config format.

  2. 02

    Configure the edges

    Domains, resources per service, environment variables, secrets, and which volumes need durable storage. The Compose file stays the source of truth.

  3. 03

    Deploy to managed infrastructure

    Services come up on an isolated private network with TLS issued, volumes attached, and health checks armed. No boxes to prepare.

  4. 04

    Operate from one control plane

    Logs, metrics, backups, restarts and rollbacks for the whole stack in one dashboard — web apps, workers and internal services alike.

Every service in the stack gets

  • Private DNSservices resolve by Compose name
  • Health checksunhealthy containers get restarted
  • Restart policiesrestart: unless-stopped honoured
  • Streaming logsper-service, searchable
  • MetricsCPU, memory, network per service
  • Durable volumesdata survives every redeploy

Features

The operational layer, built in

Opinionated about one thing: running Compose stacks properly. Everything marked planned is still being built — early-access members get it first.

  • Compose-first deployments

    The Compose file is the interface, not an export format. Services, dependencies, env files and volume declarations map directly onto the platform.

  • Persistent volumes

    Named volumes are attached to durable storage and re-mounted on every deploy. Stateful services are first-class citizens, not an edge case.

  • Private service networking

    Every stack gets an isolated internal network. Services talk by Compose name; nothing is public unless you explicitly expose it.

  • Automatic HTTPS and domains

    HTTP services get a domain and managed TLS out of the box. Point your own domain at the stack when you're ready.

  • Logs and health monitoring

    Streaming per-service logs, health status and resource metrics in one place. When a container dies, you see why — and it restarts itself.

  • Scheduled backups

    Volume snapshots on a schedule, encrypted at rest, restorable from the dashboard. Retention scales with your plan.

  • Workers and long-running services

    Queue consumers, schedulers, bots and daemons run as first-class services. No HTTP port required, no hacks to keep them alive.

  • Internal databases, done safely

    Postgres, MySQL, Redis and friends run inside your stack's private network with persistent storage — for your apps, not as public database hosting.

  • Scale the services that should scale

    Stateless services can run multiple replicas across managed infrastructure. Stateful services stay safe on durable volumes. No magic elasticity claims.

  • Resource-based plans

    Pay for a slice of CPU, memory and storage — then run your whole stack inside it. Not a meter running separately on every service.

  • A safer runtime model

    No privileged containers, no host networking, no host filesystem or Docker socket mounts. Restrictions are architectural, so multi-tenant stays sane.

  • Planned

    Curated templates

    One-click stacks for common workloads — starting with game servers like Minecraft — with persistent data and ports pre-wired. Your own Compose always works too.

Real-world stacks

Designed for the stacks people actually run

Not demos. The shape of things that are currently sitting on a VPS somewhere, held together with cron and hope.

SaaS application

web · worker · postgres · redis

webworkerpostgresredis

ComposeHost handles

  • HTTPS domain
  • volume backups
  • worker restarts
  • private networking

Automation hub

n8n · postgres

n8npostgres

ComposeHost handles

  • always-on scheduling
  • persistent workflows
  • TLS for webhooks

Discord bot

bot · redis

botredis

ComposeHost handles

  • no port needed
  • auto-restart on crash
  • state survives deploys

Internal tools

admin · api · postgres

adminapipostgres

ComposeHost handles

  • internal-only services
  • secrets injection
  • nightly backups

Agency client sites

per-client isolated stacks

client-aclient-bclient-c

ComposeHost handles

  • isolated stacks
  • own domains
  • one dashboard for all of them
Templates

Game servers and more

Curated templates ship common workloads pre-wired: Minecraft first — persistent world, TCP port, sane memory defaults — with more to follow. Same platform, same control plane, just faster to start.

minecraft · valheim · …

Why this exists

The gap between a VPS and Kubernetes

Every existing answer trades away something you probably want. Here's the honest map — including where ComposeHost is not the right tool.

A raw VPS

Cheap, flexible, full root access. Nothing between you and the machine.

  • Every operational task is yours, forever
  • One box = one point of failure
  • Scaling means a bigger box, not more boxes

Self-hosted panels

Coolify, Dokploy and friends put a nice UI on your own server.

  • You still own the machine underneath
  • The panel helps; the host still fails, fills up and needs patching
  • Backups and monitoring are still your config to maintain

Hosted PaaS

Railway, Render et al. are genuinely easy for a single service.

  • Multi-service stacks get fragmented and pricey
  • Per-service metering punishes the web+worker+db shape
  • Persistent workloads often feel like second-class citizens

Kubernetes

The real thing: powerful, scalable, ecosystem for everything.

  • Weeks of learning before the first deploy
  • Designed for platform teams, not a 3-person SaaS
  • Massive overkill for most Compose-shaped apps

The middle path

ComposeHost

Simpler than Kubernetes. Less manual than a VPS. More stack-shaped than a per-service PaaS. The operational layer exists so you can stop being your own platform team.

  • Compose stays the interface — no new DSL to learn
  • The infrastructure underneath is managed, not yours
  • Persistent volumes, backups and private networking built in
  • Stateless services scale; stateful services stay safe
  • One resource plan per stack, not a meter per service

Where it's not the right tool: if you need root access, custom kernel modules, or you're running hundreds of services with a platform team — you already have better options.

Pricing

One plan per stack, not a meter per service

Final prices aren't set yet — this is the intended shape. Each plan is a fixed allocation of compute, memory and storage that your whole Compose stack runs inside.

Starter

pricing soon

Personal projects and prototypes that deserve better than a forgotten VPS.

  • Shared compute slice
  • One Compose project
  • Persistent storage
  • Automatic HTTPS
  • Scheduled backups

Developer

pricing soon

Production apps with workers, databases and a real domain.

  • Multiple services per stack
  • More compute and storage
  • Custom domains
  • Scheduled jobs
  • Longer backup retention

Team

pricing soon

Agencies and small teams running stacks for more than one product or client.

  • Multiple projects
  • Team access controls
  • Separate client environments
  • Higher resource limits
  • Priority support

Early-access members get introductory pricing and direct input on how the final plans are shaped.

Early access

Help shape the platform

ComposeHost is being built with its first users, not just for them. Join the list to get an invite when your cohort opens, introductory pricing, and migration help moving your stack off that VPS.

  • — Invites go out in small cohorts so the platform stays stable.
  • — The two text fields below directly influence what gets built first.
  • — Early members get introductory pricing and a migration hand.
  • — No marketing drip. Launch updates only, unsubscribe anytime.

We'll only email you about ComposeHost launch updates and your invite. See the privacy notice.

FAQ

Straight answers

Including the parts that aren't finished — and the things the platform deliberately won't do.

What is Docker Compose hosting?

You describe your application as a set of containers in a Compose file — web, database, cache, worker — and the platform runs those containers for you: building or pulling images, wiring up networking, TLS, storage, backups and monitoring. The Compose file is the interface; managed infrastructure sits underneath.

Will my app magically scale?

No — and be suspicious of anyone who says it will. Stateless services can run as multiple replicas across managed infrastructure. Stateful services like databases are kept safe on durable volumes with backups, and scaled deliberately rather than automatically. It's a safer path from single-server Compose to managed infrastructure, not infinite elasticity.

Can I deploy an existing docker-compose.yml file?

Yes — that's the primary workflow. Paste it, upload it, or point ComposeHost at the repository containing it. Single images and repositories with a Dockerfile are supported too.

Will every Compose feature be supported?

No, and that's deliberate. Privileged containers, host networking, host filesystem mounts and Docker socket mounts are not supported, and device passthrough may not be available initially. Some Compose directives are translated into the platform's internal workload model rather than executed verbatim. Unsupported directives fail at deploy time with a clear explanation — not a silent behavioural change.

Can I run databases?

Yes. PostgreSQL, MySQL, Redis and similar run as normal Compose services backed by persistent volumes, on the stack's private network. They're intended for use inside your stack rather than as publicly exposed database hosting.

Where is persistent data stored?

Named volumes are attached to durable storage managed by the platform and re-attached on every deploy. Data survives restarts, redeploys and image updates.

Are backups included?

Yes — scheduled volume backups are part of every plan, with retention varying by tier. Restores are initiated from the dashboard. As with any backup system, you should still keep your own copies of anything irreplaceable.

Can I expose TCP or UDP ports?

HTTP/HTTPS services get managed routing and TLS automatically. Raw TCP exposure is planned for services that need it — game servers being the obvious case. UDP support is on the roadmap but not committed for the first release.

Can I host Minecraft or other game servers?

Minecraft will be one of the initial curated templates: a pre-configured Compose stack with a persistent world volume, a TCP port and sensible memory defaults. More game templates are planned using the same mechanism — but the platform itself is general-purpose Compose hosting, not a game panel.

Do I need to know Kubernetes?

No. There is no Kubernetes exposed anywhere in the product. If you can write a Compose file, you can use ComposeHost.

Can I deploy from a private container registry?

Private registries (GHCR, Docker Hub private repos, and others) are planned with per-stack registry credentials. Public images work from day one.

Which regions will be available?

Initial hosting is in European cloud regions. Additional regions are planned as the worker fleet grows — early-access members will be asked where they need capacity.

When will the platform launch?

There's no fixed public date. The platform is in active development and invites will go out in small cohorts. Joining the early-access list is the only way to get a date that means anything.