Might as well call it Zerops 3.0 — huge updates and what's next

After the last update in April 2025, we had a decision to make. Zerops had found its audience — hundreds of developers running projects of all sizes, 99.9998% uptime of user applications, and people appreciating exactly what we'd focused on: flexibility, affordability, scalability and developer experience. Our philosophy seemed to resonate:

But the platform was still missing a few things that mattered — multi-region, a proper role system, and modern auth (passkeys, 2FA, U2F). These gaps trace back to 2020, when we chose to build Zerops from the ground up — system containers instead of Kubernetes, no big cloud abstraction layer underneath. We started from our own datacenter and inherited the auth layer of our parent company at the time. That gave us the architecture and speed we wanted early on, but it meant multi-region and auth couldn't just be bolted on later — they had to be rebuilt from scratch.

So instead of pushing growth on an incomplete platform, we went quiet and built. Now we're ready. On the first of March 2026 we launched the US-East region (US-West and Asia are weeks away), the table stakes features are done, and our new website capturing the philosophy is up.

Here's everything we've added and improved since April 2025.

• Multi-region
• 2FA, Passkeys & user tokens
• Roles, permissions & integration tokens
• Domains & routing
• Advanced observability
• Backup management
• Build & egress reporting
• Logs improvements
• PostgreSQL
• Recipe system & onboarding
• Other improvements
• What's next
• A big thank you

Multi-region

US region is live. You choose EU or US when creating a project. Funny how something that required a major rewrite of every single layer of the platform can be summarized in so few words and just a single toggle in the UI. More regions are coming, but a US presence was the critical first step. Other variations of multi-region like edge multi-region are coming later this year.

2FA, Passkeys & user tokens

The new auth system supports FIDO2/WebAuthn passkeys — hardware keys, biometrics, whatever your device supports. On top of that, TOTP-based 2FA via authenticator apps, sudo mode that re-authenticates you before sensitive operations like managing 2FA settings, and personal access tokens you can generate and manage from the settings for use with the CLI, API, or any automation you need.

Roles, permissions & integration tokens

Four roles — Owner, Admin, Developer, Guest — with organization-wide defaults and per-project overrides. An Admin who needs full access to dev projects but read-only on production? Set an override on the production project. A contractor who should only see one project? Invite them as Guest, grant access to that project, revoke when they're done.

The part we're most happy about is integration tokens. These are tied to your account but scoped to exactly the access level you choose — full access to all projects, read-only, or custom per-project permissions. Perfect for CI/CD pipelines, GitHub Actions, GitLab CI, deployment scripts. The token value shows once, you store it, and it works until you regenerate or delete it. No more passing around personal credentials.

Domains & routing

We overhauled domain management — new DNS workflow and a redesigned UI. But there are two bigger changes here.

First, there's a new project-level routing & access page that gives you a single view of everything networking-related for your project — L3 balancer with IP addresses, egress graph, direct IP access to services, HTTP balancer configuration with all your domain routes, VPN access, and registered SSH public keys. Before, this information was scattered across service-level settings. Now there's one page for the full picture.

Second, each route now has its own advanced configuration. Every location ({domain}/path → service:port) can be individually configured with redirects (with options to preserve path and query), IP-based access policies (allow/deny by CIDR block), rate limiting (per IP or per domain, with burst handling), basic auth, and custom content responses. Previously this kind of thing meant asking us or hacking around it.

The L7 balancer itself is also fully configurable now — connection handling, client request settings, buffer sizes, proxy settings, gzip, WebSocket support, all exposed per project.

For context, in Zerops, every project gets its own dedicated internal infrastructure with L3/L7 balancer that is independent from Zerops control plane, so it keeps working even if parts of Zerops don't.

Advanced observability

You could always run ELK or Prometheus on Zerops, but now there are first-class observability recipes. Deploy a full logging or monitoring stack with a single click — properly configured for the platform, with the right resource allocations and service connectivity. We also added the Advanced Observability section inside project settings, where you can configure log forwarding to external systems and set up metrics and tracing exports.

If you're running anything serious, you probably want one of these running alongside your project.

Backup management

Zerops always did automatic daily backups, but you couldn't control them. Now you can — custom schedules, configurable retention policies, and protected tags that prevent specific backups from being auto-deleted. You can also create and download manual backups from the UI or CLI, and everything is encrypted end-to-end.

Build & egress reporting

You can now see egress graphs and spend tracking directly in the dashboard. Builds and egress are billed separately from resources, and before this, it wasn't always obvious what was generating costs. Now you can see the breakdown and track it over time.

Logs improvements

Two things. Log search — you can now filter and search directly in the log output instead of scrolling through everything. And format switching — logs can be viewed as plaintext or structured syslog formats, switchable in the UI. Useful when you need structured fields for debugging versus just eyeballing output.

PostgreSQL

Postgres got dedicated attention this cycle. Direct IP access with TLS — you can now connect to Postgres externally over IPv4 or IPv6, with TLS termination handled by PgBouncer. Read replicas have a dedicated read port (5433), so you can split read/write workloads by pointing reads to a different port without any application-level routing. TimescaleDB and json_schema extensions are available. And general stability improvements across the board for HA setups.

Recipe system & onboarding

We rebuilt the entire recipe system from scratch — and this one deserves more than a bullet point.

A recipe isn't a starter template. It's productized DevOps knowledge — a tested infrastructure topology with correct service configurations, proper resource allocations, and working connectivity between services. You see the exact topology and what it costs before you deploy.

After deployment, you choose your path — template (clone the repo, follow an environment-specific guide, ship) or integrate (bring your own code, get per-service guides for connecting to what the recipe deployed). The guidance adapts to your target environment because the underlying infrastructure does too — dev and production aren't just labels, they're different topologies.

Behind it is a layered knowledge base — platform concepts, service-type references, per-app guides, and recipe-specific operational content — so you're learning the platform while working, not before you start.

For existing users, recipes are reusable infrastructure patterns. Need a production-ready observability stack or a properly configured Postgres cluster? Deploy the recipe, take over what you need, customize from a working baseline instead of building from scratch.

This deserves its own writeup, and it's getting one.

Other improvements

Pipeline triggers: You can now trigger and re-trigger build pipelines from the service detail, using a public git repository or custom pipeline configuration. Re-trigger the last pipeline with different env variables.

Dark mode: Full dark theme across the entire dashboard.

Environment isolation: Services now default to strict variable isolation — each service can only access its own variables and must explicitly reference others. You can configure this per service, or set the default for the whole project and override it on individual services where needed.

Static service headers: The static service now supports custom headers and a cors shorthand in `zerops.yml`:

zerops:
  - setup: app
    run:
      base: static
      routing:
        cors: "'*' always"
        headers:
          - for: /*
            values:
              My-Custom-Header: Hello

zCLI: push creates projects and services inline if they don't exist. New project env command for managing env vars from the terminal. Project scoping so you stop passing project IDs everywhere. New VPN subcommands (vpn clear, vpn key), macOS DNS resolver fixes, .deb packages for Debian/Ubuntu.

New service versions: Node.js 24, Python 3.14, PHP 8.5 (Ubuntu & Alpine), Bun 1.4, PostgreSQL 17 & 18, Elasticsearch 9.2, ClickHouse, Meilisearch 1.20, NATS v2.12.

Dashboard QoL: Connection strings copy with credentials, env var key/value pairs copy cleanly, all service ports visible in basic info, webshell saves bash history, destructive actions require confirmation, documentation links throughout the app, editable project-generated env vars.

What's next

Our team recently tripled in size, including Francesco leading DevRel — expect to see us at conferences and hear from us a lot more this year.

From the product side we also have a couple more exciting features in store:

Zerops Control Panel (ZCP)

AI coding agents — Claude Code, Cursor, Codex, OpenCode — are fundamentally developers. They write code, test it, iterate, and deploy. But the infrastructure most developers use for AI-assisted development forces agents into sandboxes and mocks, producing code that "works" in isolation but fails in production.

ZCP is a container running inside your Zerops project — a high-level prompt and MCP server that gives your AI agent SSH and filesystem access to your real dev and staging services over the project's private network. Same managed Postgres, same Redis, same S3, same deployment pipeline. The agent develops against real infrastructure, verifies through zcli push to staging, and hands off production-ready code — no mocks, no environment drift.

Expect to hear more about this very soon, with public preview aimed at May.

Notification system

You'll be able to select the frequency and granularity of the notifications and alerts you receive, as well as set up webhooks to send them wherever you need.

Edge multi-region

Right now our multi-region allows you to run whole projects inside a selected region, which is great if your visitors are largely from a single continent. But there are obviously use cases where your visitors are from all over the world. For these we'll add the ability to run containers of a single service across multiple regions — using the same long-running, system containers-based approach. Think your API service responding from the closest server, your databases having read nodes in the nearest region.

Massive improvements to managed services

Starting with Postgres and MySQL (MariaDB), we plan a multitude of improvements, including profiles, advanced performance tuning, point-in-time backup / recovery, cloning / forking, as well as AI-based optimization suggestions.

Open source software recipes

Currently our recipe system focuses on runtime languages and frameworks — the things you build on top of. But equally important is running open source software that you just utilize: auth, observability, community, analytics, project management, backend-as-a-service.

These projects always provide a self-hosted option, but oftentimes it's just a Docker image and docker compose up — great for testing locally, unusable for serious production. We want to provide these applications as one-click deployments in a production-ready setup, with a guide on how to maintain, upgrade and operate the software.

A big thank you

A year ago we made a bet: stop promoting, stop chasing growth, and rebuild the foundation. Every layer — auth, multi-region, roles, networking — touched from the bottom up. That's the kind of decision that looks obvious in hindsight and terrifying in the moment.

What made it possible was the hundreds of developers who found and kept using Zerops while we were building in the shadows — who proved through their production workloads that this middle ground between magic-box PaaS platforms and complex big cloud setups isn't just viable, it's what a lot of developers actually want.

The foundation is done. What comes next is the full push — but you're hearing it here first.

If you're new to Zerops, sign up here. If you tried us before and ran out of credits, email dev@zerops.io and we'll give you a refill.

See you at the starting line, Aleš, Honza and the Zerops team.