Dora NodaFor two and a half years, ZaneOps had exactly one human in its permission model: you, the person who ran make deploy on the box. The v1.14 release on August 31, 2026 changes that more fundamentally than any release since v1.0 — workspaces, four roles, team invitations, a server admin area, and, for the first time, an optional paid license. The ceiling on a ZaneOps instance moved from "one human" to "one fleet."
That sentence contains the whole verdict, but the details decide whether your team should care. Here is the accounting up front:
| What v1.14 changes | What it doesn't change |
|---|---|
| One admin becomes a team: workspaces with Viewer / Member / Admin / Owner roles and per-project scoping | The fleet is still one Swarm: dashboard-managed multi-server support remains roadmap |
| Free tier covers 1 workspace and 3 users; a Starter license buys more of both | The core stays MIT-licensed; paid features live in a separate Enterprise Edition image |
| Instance ops get a real home: prune schedules, retention policies, master HTTP logs | Machines still arrive by joining the Swarm, not by registering in the dashboard |
| Tracing (OTLP to Tempo/Grafana) and GeoIP (local MaxMind lookup) arrive as opt-ins | Both ship disabled; you bring the stack file and the database |
If you are a team of three or fewer running one server, v1.14 is the release that makes ZaneOps a team tool at zero cost. If your problem is the second machine rather than the second human, keep reading — that is where the honest limits are.
What v1.14 actually ships
Some context on what the release builds on. ZaneOps is a self-hosted PaaS that maps every service one-to-one onto a Docker Swarm service, with Caddy as the single HTTP entrypoint, a Django backend, and Temporal-orchestrated deploy workers. The v1.13 release in February added the deployment surface most teams actually want: native docker-compose.yml stacks (deployed as Swarm stacks with blue/green rollouts, domain assignment via labels, and template expressions for generated values), one-click templates, shared volumes, and reusable registry credentials. Underneath, the Railpack builder — Railway's open-source Nixpacks successor, promising faster builds and smaller images — is available in beta. The project is small but alive: roughly 1,400 GitHub stars since its February 2024 start, with commits landing within days of this writing.
On that foundation, v1.14's headline is workspaces. Every project, git app, and resource now lives inside a workspace, and a large database migration backfills one for your existing projects on upgrade. Each member gets one of four roles:
| Role | Can do | Scoping |
|---|---|---|
| Viewer | Read everything except secrets (env vars hidden) | Can be limited to specific projects |
| Member | Edit configuration, manage env vars, trigger deploys | Can be limited to specific projects |
| Admin | Invite/remove members, change roles, delete services, manage API tokens | Full workspace, but cannot delete it |
| Owner | Everything, including deleting the workspace | The workspace creator |
Invitations work by username: existing accounts join immediately, everyone else gets an expiring, revocable invitation link carrying the role and project scope you picked. The dashboard was reworked around the model, with a trimmed layout for members and viewers that only surfaces what they may touch. This is a genuinely well-shaped permission ladder for a first multi-user cut — the read-only-but-secrets-hidden Viewer and per-project scoping are exactly the two features that separate "we added logins" from "a contractor can safely look at staging."
The release also gives the instance owner a server admin area, separate from every workspace: cron schedules for docker system prune and app-data cleanup, HTTP-log and build-cache retention policies, fine-grained control over what prune removes, and master HTTP logs spanning all projects — including ZaneOps' own traffic and the 404 catch-all. Two observability features arrive as opt-ins: GeoIP, which adds a request-country column and filter to every HTTP logs page via a purely local MaxMind lookup (ZaneOps ships no database and never phones home; the feature stays off until you set MAXMIND_DB_HOST_PATH), and OpenTelemetry tracing, which exports API traces over OTLP into Tempo and Grafana, on by default in development and enabled in production through a dedicated stack file. Rounding out the release: a rebuilt ⌘K command bar unifying navigation, actions, and search, plus deploy logic that finally detects stuck Swarm rollouts instead of reporting them as successful.
One upgrade note with teeth: v1.14 changes the Docker stack and runs that large workspace-migration, so the documented path is re-downloading the Makefile and re-running make setup before deploying. Budget a maintenance window, not a coffee break.
The paid license, honestly accounted
v1.14 is also the release where ZaneOps starts charging for something, so the licensing terms deserve a careful read. The shape is better than most open-core debuts.
The free tier is 1 workspace and 3 users (members plus pending invitations counted together). Everything else — unlimited projects, services, environments, deployments, preview environments, compose stacks, git apps — is unaffected by licensing. A team of three on one box pays nothing and loses nothing. The paid Starter tier unlocks exactly two things: more than one workspace on the same instance, and more than three users. More gated features are promised for later versions; today the license is purely a seats-and-workspaces key.
The mechanics respect the MIT promise. Licensing code lives only in the Enterprise Edition image (ghcr.io/zane-ops/app:ee-<version>); the default image contains no licensing code at all, and the license page is simply absent from it. Switching means adding the ee- prefix to the image tag on three services (the app plus two Temporal workers — the proxy is unchanged) and redeploying.
A license is a signed key issued by the ZaneOps license server, bound to an instance fingerprint, re-validated roughly every 12 hours, with one license per instance. Two consequences fall out of that design: fully air-gapped instances stay on the free tier, since install and re-validation both require reaching the license server; and if a license expires or is removed while you are over the limits, existing resources keep working — you just cannot create workspaces or invite users until you are back under the limits or install a valid key again. No hostage-taking of running workloads.
The open question is price, which lives on the ZaneOps site rather than in the docs, and breadth: "extra seats" is a thin paid tier today, which is fine for buyers (the free tier is generous) but means the project's commercial sustainability is still unproven. Evaluate the license for what it unlocks now, not the roadmap.
What it doesn't change: the second machine
Here is the limit the release notes imply but never state: v1.14 is multi-user, not multi-server. Nothing in the release manages a second machine from the dashboard. Capacity still arrives the Swarm way — you join nodes to the Swarm outside the PaaS, and ZaneOps schedules services onto the bigger pool.
The tell is in v1.13's changelog, where S3-backed build registries were introduced explicitly "in preparation for multi-server support": images needed a shared home before builds could run anywhere but the box. That preparation is more than seven months old with no dashboard-managed servers yet, and the v1 roadmap still lists multi-server support as future work.
That puts three self-hosted philosophies side by side, and the choice between them is really a choice about what "the second machine" means to you:
| ZaneOps (v1.14) | Coolify | Cluster API fleet | |
|---|---|---|---|
| Second machine arrives via | Joining the Swarm at the infrastructure layer | Registering an SSH remote in the dashboard; each app targets a server | A declarative MachineDeployment reconciled by a provider |
| Who provisions the OS | You, by hand or your own tooling | You, by hand; Coolify installs Docker over SSH | The provider (e.g. CAPH on Hetzner) |
| Build offload | Shared registry preps for it; not yet multi-server | Dedicated remote build server supported | Native: builds schedule anywhere |
| Multi-user story | New in v1.14: workspaces, 4 roles, per-project scoping | Teams exist but RBAC is team-level (Admin/Member), no per-project scoping | Whatever your IdP + RBAC gives you |
| Best fit | One team, one box (or one hand-built Swarm) | Several boxes managed from one dashboard by hand | A fleet whose machines are cattle |
Coolify's model — one dashboard instance managing SSH remotes, with per-app server targeting — is the most literal answer to "I bought a second VPS," as our September showdown of second-machine costs walked through. A Cluster API fleet goes further: machines are declarative API objects with lifecycle, repair, and upgrades, which is what you want when nodes come and go.
ZaneOps sits deliberately below both on the infrastructure axis. Swarm scheduling stops where machine lifecycle starts — nobody is going to reconcile your dead node back — and v1.14 doesn't move that line. What it moves is the human axis, and notably it leapfrogs Coolify there: Coolify's RBAC is team-level Admin/Member with no per-service permissions, while ZaneOps' new Viewer role and per-project scoping answer the contractor-on-staging case on day one.
There is a coherent strategy in that ordering. Multi-user on one box serves every team outgrowing a shared admin password today; dashboard multi-server serves the subset that outgrows one box tomorrow. ZaneOps picked the larger cohort first.
Should your team adopt it now?
Adopt v1.14 if you are a team of up to three running (or planning) a single server, especially if your workloads are already compose-shaped — v1.13's native compose support plus blue/green deploys is the real deployment story, and v1.14 adds the team layer it was missing. The free tier covers you completely, the MIT core means the EE image is a choice rather than a migration, and the permission model is good enough for contractors on day one.
Wait if your constraint is machines rather than humans: dashboard-managed multi-server is still roadmap, and joining Swarm nodes by hand inherits all of Swarm's own operational sharp edges with no PaaS help. Wait as well if you are air-gapped and need more than three users — the license server's 12-hour re-validation makes the paid tier unreachable without egress. And if you already run Kubernetes or a CAPI fleet, v1.14 is not a reason to move sideways; Swarm simplicity is the product, and this release doubles down on it rather than bridging toward orchestration you already have.
One forward-looking signal is worth noting: v1.15, weeks later, built directly on the workspace model with scoped API tokens (role, scopes, projects, expiry) and locked down the previously public deploy webhooks behind them — a breaking change that returns 401 on old webhook URLs until you add a bearer token. Workspaces are clearly the foundation, not the feature: tokens, and presumably everything team-shaped next, hang off them. That is the trajectory to bet on or against.
ZaneOps spent two years becoming the nicest single-admin Swarm PaaS. v1.14 spends that capital on the right next problem: the team standing behind the admin. The box is still one box — but at least now the whole team can share it safely.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
