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.
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.
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.
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.
Push code via GitHub, GitLab, or zcli push
Temporary build container created from build.base — up to 5 CPU, 8 GB RAM, 100 GB disk. Included in your project core.
build.prepareCommands install system dependencies into the base image. Cached — only rebuilds when config changes.
build.buildCommands run your build. Only files matching build.deployFiles ship to runtime.
Runtime container from run.base , customized via run.prepareCommands . Cached independently — persists across deploys.
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.
infrastructure
core with routing
and balancing
with system containers
Develop your way.
Your agent works the same way.
Cloud IDE without browser lock-in. Local setup without machine lock-in. Coding agent with real platform reach.
Every Zerops project is a private network with managed services and a deploy pipeline. Develop against it locally or remotely. Run zcli vpn up and your laptop's psql hits db:5432 directly. Open the Cloud IDE for a clean browser session. SSH from your native VS Code, JetBrains, or Cursor into a runtime container. Switching paths is moving the cursor, not the project.
Same access for a coding agent. Bring your own LLM, and ZCP makes it a Zerops power user — platform knowledge that follows your project's state and the task at hand, plus tools to operate every part of Zerops. It deploys through the pipeline, reads logs, verifies behavior, and ends a session with a URL or a concrete blocker. Security is solved at the architecture level: dev and stage live in one Zerops project, production in a matching one the agent never sees.
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.
with system containers
on Zerops
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
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.
100 GB egress, 15 hours build hours, 5 GB Backup storage, single container