Greentic deploys digital workers. Until now, the record of what is deployed where lived as files on one operator's machine. "Server Next" turns that into a real, shared, safe control plane — a server many operators and automations talk to over the network. Here's why that matters, what already works, and what's left.
The short version: a file on a laptop is fine for a demo, not for an enterprise.
Each of these is a way the laptop-spreadsheet model fails — and a thing the server must get right.
Reachable over the network, not a file only one person can see.
Two operators editing at once can't overwrite each other — writes are checked against a version tag (optimistic locking).
If a network glitch makes a client retry "deploy", it must not deploy twice — the server replays the first answer instead.
Every change — and every rejected attempt — is written to an audit log for compliance.
Who may change what, decided per person + environment + action, and locked shut by default.
Snapshots you can restore, and integrity checks that catch silent data rot before it spreads.
The plan sequenced the work so each phase builds on the one before it. Below is the plan and where each phase actually stands today.
The plan said "finish the Postgres backend first." In practice the team shipped a simpler single-writer SQLite server first — it works today and ships sooner — and parked Postgres as a prototype to revisit when scale or high-availability demand it. A deliberate change of order, not a skipped step.
A real server (greentic-operator-store-server) now exposes the deployment contract over HTTP. Version-tag locking (guarantee ②) and retry-safe replay (③) are built in. --store-url works end-to-end: an operator can apply an environment to a remote server, and even dry-run it first to confirm it would converge.
Decisions are made per actor + environment + action, fail-closed, and rejected attempts are still audited (guarantees ④ & ⑤). Today it uses static bearer tokens with coarse roles (admin / operator / read-only). The future piece is stronger identity — OIDC or mutual-TLS — which can replace this module without changing anything downstream.
The "stage a new revision → warm it up → drain → archive" lifecycle is wired through the server, with a clean split between the pure decision logic and the database write. These were the actions left unimplemented when the plan was written.
This is the gate for "production-ready", and most of it is done: the retry-log is bounded, the audit log has opt-in retention that records what it trimmed, corruption detection verifies hashes on load, and backup & restore exists with tests. Remaining: a full backup→restore acceptance drill and high-availability (automatic failover to a standby).
A lot of this was "finishing", not greenfield — the wire contract and the client existed before the server did.
--store-url routing on the operator CLI.| Item | What it adds | Status |
|---|---|---|
| Backup→restore drill | A single end-to-end acceptance test proving that taking a backup and restoring it reproduces the exact live state ("active generation"). The mechanism exists and is unit-tested; this is the production sign-off proof. | Next |
| Identity beyond static tokens | OIDC or mutual-TLS so actors are real verified identities, not shared bearer tokens. Designed-for: it can swap in without touching downstream code. | Future |
| High availability | A standby server that takes over automatically without losing any committed change. Needs a design decision (shared storage vs. replication) first. | Future |
| Postgres backend | Finish the parked Postgres path for when one SQLite writer is no longer enough. Reopen when scale/HA forces it. | Parked |
The control plane is working end-to-end: a shared server with locking, retry-safety, audit, access control, the full deploy lifecycle, and recoverable backups. The remaining work is the production sign-off drill and the enterprise-grade extras — verified identity and automatic failover.
Greentic deployment · "Server Next" (Part 2 of the plan). Status reflects the greentic-operator-store-server work through the latest develop. Phases S2 and S4 shipped; S3 shipped at the static-token level; S5 mostly shipped (drill + HA remain); S1 re-sequenced to SQLite-first with Postgres parked.