Cloud that respects developers — human and AI.
Full Linux containers, managed services, a dedicated
private network — from remote / agent environments
to highly-available prod, nothing changes but scale.

Is Zerops for you? What is your tech stack?

Try Zerops in < 5 minutes without installing or forking anything — deploy one of our curated recipes, which are examples covering the full development lifecycle from local dev through staging to production, with built-in seeding, migrations, backups and scaling.

Your favorite language / framework not covered by our recipes? Deploy the Showcase recipe, or join Zerops Discord and we'll help you out.

"Hello World" Examples Bun Python

Production-ready image processing pipeline showcasing distributed architecture on Zerops — a Bun + React frontend with real-time WebSocket updates and live architecture visualization, a Python worker for async image processing via NATS, backed by PostgreSQL, Valkey, and S3-compatible object storage.

Project core
Lightweight

100 GB egress15 hours build hours5 GB Backup storagesingle container

Free
app:3000
Bun
1 Shared Core
0.5 GB RAM
1 GB Disc
worker
Python
1 Shared Core
0.5 GB RAM
1 GB Disc
db:5432:6432
PostgreSQL
1 Shared Core
0.25 GB RAM
1 GB Disc
redis:6379:6380
Valkey
1 Shared Core
0.125 GB RAM
1 GB Disc
queue:4222:8222
NATS
1 Shared Core
0.25 GB RAM
1 GB Disc
storage
Object storage
External    5GB Disc
7 Shared Cores
2.625GB RAM
7GB Disk (SSD)
5GB Object storage
$12.83 per month

Pricing model that doesn't get in the way of good development practices — no feature tiers, no seat fees and minute-based pricing combined with automatic scaling ensures you only pay for what your apps need, at one of the lowest rates amongst popular PaaS.

ProjectPrivate VXLAN network
Dedicated
infrastructure
core with routing
and balancing
Project ctrl & L3/L7 balancer + firewall + stats + logger
Dedicated infrastructure core
Project ctrl & L3 balancer + firewall
Stats
Logger
Dedicated routing and balancing
L7 HTTP balancer
Your services
with system containers
db:5432
worker
app:3000
redis:6379
queue:4222
Container resources
Shared CPUper 1 core
$0.60
1 – 8 core
Dedicated CPUper 1 core
$6.00
1 – 8 core
RAMper 1 GB
$3.00
0.125 – 48 GB
Diskper 1 GB
$0.10
1 – 250 GB

Up to 50 containers for runtime services. HA / non-HA modes for managed services.

Full Linux OS containers with root access for your applications + managed, highly available services. Built-in flexible CI/CD pipeline. Powerful, yet sensible YAML configs. Nothing abstracted beyond recognition. SSH, cron, apt-get, hostname:port — everything works the way you already know.

BunDenoGolangJavaPythonRustGleamNode.jsRubyPHP.NET

Container efficiency.
VM-level access.

Most platforms run your code in application containers — a single process in a locked-down filesystem. You've probably worked around the limitations so many times you stopped noticing them.

That background job running as a separate service because your platform won't allow two processes? That's an app container constraint. The video processing pipeline that shells out to a third-party API because you can't install ffmpeg? App container. The production issue you debugged blind because there's no SSH? App container.

System containers share the host kernel — so you get container-fast startup and density — but run a full Linux userspace. Install system packages. Run multiple processes. SSH in. Set up cron jobs. It's your environment, not a sandbox with guardrails.

App Containers
Fast startup
High density
Install packages
Multiple processes
SSH access
Zerops
System ContainersPowered by Incus
Fast startup
High density
Install packages
Multiple processes
SSH access
zerops.yaml
Install any system package
prepareCommands:
- sudo apt-get i -y ffmpeg
Run multiple processes
startCommands:
- name: api
command: npm start
- name: worker
command: npm run worker
Schedule recurring tasks
crontab:
- command: rm -rf /tmp/*
timing: 0 0 * * *
Full VMs
Fast startup
High density
Install packages
Multiple processes
SSH access

Same services. Same networking.
Same pipeline. Different scale.

"But it works on my machine."

Matching production isn't about running the same software. It's about running the same infrastructure. Postgres in Docker Compose isn't managed Postgres with replication and failover. A local Redis instance isn't a cluster with eviction policies. Load balancing, TLS termination, object storage, CORS — missing or faked. Anything complex enough — Elasticsearch, message queues, vector databases — gets skipped or outsourced to a third party that behaves nothing like production.

Zerops doesn't have environment tiers. There are just projects — same managed services, same private networking, same load balancers, same pipeline. A project becomes dev, stage, or production by the resources you give it. Nothing else changes.

Databases, caches, queues, storage —
managed means managed.

Your database shouldn't be a separate infrastructure problem.

Docker Compose gives you a disposable instance with no failover, no backups, no resemblance to production. Third-party hosted services add latency and sit outside your network. And even platforms that offer a built-in database usually stop at Postgres — caching, search, queues, and storage still mean stitching together external providers.

On Zerops, every service in the catalog is a first-class citizen of your project — same private network, reachable by hostname, credentials injected as environment variables. Health monitoring, automated backups, scaling built in. High availability is a toggle, not a tier upgrade. Whether it's PostgreSQL, Elasticsearch, Kafka, or Qdrant — managed the same way, deployed the same way, already on your network.

Zerops management
Health monitoring
Failover
Backup
Scaling
Databases
PostgreSQL
MariaDB
ClickHouse
Search
Elasticsearch
Meilisearch
Typesense
Queue
Kafka
NATS
Cache
Valkey
KeyDB
Vector
Qdrant
Storage
S3-compatible objectShared POSIX
zerops.yml

Your entire pipeline, one file in your repo.
Sensible defaults. Full control.

zerops.yaml defines your entire application lifecycle — build and runtime images, deploy strategy, readiness checks, cron jobs, service connections. Version-controlled in your repo.

Prepare your build image with system-level dependencies. Build your app. Prepare a custom runtime image with the packages your app needs at runtime. Deploy artifacts into it. Zerops caches both images independently — rebuilds only happen when configuration changes, not on every push.

New containers start alongside old ones, pass a readiness check that can verify your entire stack — database, cache, queue, storage — then traffic shifts over. Zero downtime by default. Every service keeps its last 10 versions. Rollback is activating a previous one, not a rebuild. Prod and dev live as setup variants in the same file. And it all runs on the same system containers — full Linux userspace, not a locked-down sandbox.

1
1
Trigger deploy

Push code via GitHub, GitLab, or  zcli push

2
2
Create build environment

Temporary build container created from  build.base  — up to 5 CPU, 8 GB RAM, 100 GB disk. Included in your project core.

3
3
Prepare build imageoptionalcached

build.prepareCommands install system dependencies into the base image. Cached — only rebuilds when config changes.

4
4
Build & collect artifacts

build.buildCommands run your build. Only files matching  build.deployFiles ship to runtime.

5
5
Prepare runtime imageoptionalcached

Runtime container from  run.base , customized via  run.prepareCommands . Cached independently — persists across deploys.

6
6
Deploy & verify

New containers start alongside existing ones. Once  deploy.readinessCheck passes, traffic shifts over. Old containers retire. Zero downtime by default.

Private by default.
Independent once running.

Not shared infrastructure with tenant isolation. A dedicated network, dedicated balancers, dedicated firewall — per project. And after deployment, your project doesn't depend on us to keep running.

Why does this matter? Real service discovery — db:5432, cache:6379, api:3000, standard hostname resolution, no proprietary SDKs, no service mesh. Debuggable topology — when something breaks, you're looking at your network, not a shared one where the problem could be anyone's. Predictable behavior — dedicated load balancers mean your routing, TLS termination, and firewall rules are yours alone.

Each project runs on a separate VXLAN with dedicated L3 and L7 balancers, internal DNS, and automatic TLS. Connection strings don't change between environments. Run zcli vpn up and your local machine joins the same network — access every service by hostname from your laptop.

https://my-app.com
ProjectPrivate VXLAN network
Dedicated
infrastructure
core with routing
and balancing
Project ctrl & L3/L7 balancer + firewall + stats + logger
Dedicated infrastructure core
Project ctrl & L3 balancer + firewall
Stats
Logger
Dedicated routing and balancing
L7 HTTP balancer
Your services
with system containers
app:3000
worker
redis:6379
load balancers
db:5432
queue:4222
Object storage External
storage

Observability is an infrastructure problem.
We treat it like one.

Every project gets its own dedicated logger and statistics services. Where the data goes is up to you.

Logs are collected via syslog-ng — not files you tail, but a structured pipeline you control. Filter and search them right in the Zerops GUI for a quick overview, or forward to a self-hosted ELK or Prometheus + Grafana stack, Betterstack, Papertrail, or any syslog-compatible target when you need the full picture. No vendor lock-in on your observability stack, no premium tier to unlock log search — just the collection infrastructure and the freedom to build the setup that fits your scale and budget.

ProjectPrivate VXLAN network
Your services
with system containers
forwarder:9090
app:3000
worker
db:5432
redis:6379
queue:4222
Dedicated infrastructure core
Stats
Logger
Project ctrl & L3 balancer + firewall
Zerops app
Self-hosted
on Zerops
Metrics stack
prometheus:9090
grafana:3000
ELK stack
logstash:5044
elastic:9200
kibana:5601
Third party
BetterStack
Papertrail
any syslog