T06-L05 · Build apps · Level 5 Operator · 19-minute read, plus 6 hours of doing over a month

Friday afternoon, three hours without orders

The reorder app from T06-L04 · Put Your Team App on the Organisation's Own Database, and Prove You Can Restore It now serves eight groups and the purchasing office. On a Friday afternoon Jonas, the deputy, asks Lovable to add a delivery date column to the list. The screens look fine in the preview. Lovable saves the change to the repository, and the server rebuilds the live app from every change there, as Aylin had set it up. The new code asks Supabase for a field that exists only in the test copy. Every list stays empty for three hours, purchasing orders nothing, and nobody knows how to go back to Thursday's version. Two weeks later IT reads that Supabase is retiring its older kind of API key by the end of 2026. The app was still built with the older key, which works alongside the new one, and nobody has put the switch on a date. Aylin, who built all of it, starts her new job in March.

In a company it's Tobias with three apps on one Supabase. The restore rehearsal he does twice a year fails: the nightly backups had stopped five weeks earlier, when the key for the backup storage expired. Nothing had alerted, because the backup job's own failure message went to a mailbox nobody reads.

You are at Level 5 Operator. When the app stops, many people's work stops, and it has to outlive the people who built it. This book gives it a way to change safely, a way back, eyes from outside, and a deputy who has done it all once.

After this you can

  • Release every change through a staging copy and put the exact same build into production.
  • Roll back a bad release in minutes, and change the data model so that a rollback loses no one's data.
  • Watch the app from outside (reachability, a real sign-in, backup age and certificate expiry) with alerts to a team channel.
  • Plan updates, licences and costs a year ahead, and review who has access every quarter.
  • Pass the builder-has-left test: a deputy releases, rolls back and restores without the builder.

Before you start

Last verified 23 September 2026. Dokploy and Supabase are free to self-host. Supabase publishes a new release of its self-hosted setup about once a month, and is retiring its older kind of API key by the end of 2026. Details for experts at the end of this book.

The idea in one page

At Level 4 you made the data safe. Now you make the changes safe, for years, and you make yourself replaceable.

Two copies, one build. Production is what people use. Staging is a second copy on its own address, with its own database of test data and its own logins. Every change goes to staging first, through the role test sheet from T06-L04 · Put Your Team App on the Organisation's Own Database, and Prove You Can Restore It. Then the same build, the same packaged version that passed, goes to production. Building again for production would give you a version nobody has tested.

A rollback you've done. Dokploy can put the previous build back in about a minute, because it keeps each build in the registry. That covers the app. The data needs one more rule: change the data model in two steps. First add (a new field, the old ones stay), and release the code that uses it. Only in a later release, once nothing uses the old field, remove it. Then the previous build still works with today's data, and going back never means restoring last night's database over today's orders.

Watch from outside. The server's own view says the containers run. People care whether they can sign in and see their requests. So an outside monitor checks four things:

CheckWhat it catches
The address answers, over HTTPSServer, network or gateway down
A test account signs in and sees its known test requestA release or update that broke sign-in or the permissions
Last night's backup arrivedA backup job that failed quietly
The certificate has more than 14 days leftThe padlock expiring on a Saturday

Every alert goes to a team channel with a link to the handover folder.

Plan the year. Four kinds of change reach you whether you plan them or not: updates (Supabase, PostgreSQL, the server, and the keys they use), licences and prices, people joining and leaving, and the data owner's rules changing. A one-page year plan puts each on a date.

Make yourself replaceable. Once a year, and before you leave, the deputy runs the builder-has-left test: your accounts are disabled for a day, and the deputy releases a change, rolls it back and restores a backup from the folder alone.

In the four quadrants, operating is Structure it ⇄ Understand it on repeat: you write down how the app should run, you watch how it does, and each surprise changes the page. Choose tools and Build it come in small steps: a staging copy, a monitor, a date in the plan.

Worked example: two apps, four quadrants

Follow the one closer to your work. The names, numbers and incidents are typical examples written for this book.

Lab: the reorder app changes hands

Structure it (30 min). The group leaders agree that the institute's research IT will run the app as a service, with Katrin as operator and Jonas as deputy. Aylin leaves in March. Katrin writes: "Eight groups and purchasing can order every working day. A change never reaches them untested. Any bad release is undone within 15 minutes, without losing requests. By March, Jonas and I can do everything Aylin does, and the app survives either of us leaving."

Understand it (2 hours over a week). She reads the Friday incident with Jonas. The cause was simple: every change saved in Lovable went straight into the repository branch the live app is built from, and the new field existed only in the test copy. Nothing stood between a change and eight groups.

Then she lists what Aylin does that nobody else knows. There are nine items. Four are only in Aylin's head: how to rebuild the screens after a Lovable change, where the registry password lives, which policies belong to which group, and the one-off fix she runs when a group changes its cost centre. Two things hang on Aylin personally: the GitHub repository with the screens sits in her own account, and the Studio password and the secret key live only in her password manager.

She also reads the changelog for Supabase's self-hosted setup, the list of what changed in each release. The server is five monthly releases behind, and the app still sends the older kind of key.

Back to Structure it. Her first sentence was about releases. The larger job is getting everything out of one person: "Nothing about the app depends on Aylin's accounts or memory. Changes go through staging, and so do Supabase's updates, on dates in a plan."

Choose tools (30 min). IT already runs Dokploy for other institute services, so she uses it here too: it builds the screens from the repository, keeps each build in the institute's registry, and switches between builds with one action. The alternative would be a hand-written script on the server. It would work, but it's one more thing only its author understands. For monitoring, the department's Uptime Kuma. For Supabase, she brings staging up to date one release at a time before production follows, instead of jumping five releases at once.

Build it: move ownership (1 hour). The repository moves from Aylin's personal GitHub account into a GitHub organisation that the institute owns, with Katrin, Jonas and IT as its administrators. Lovable doesn't follow a moved repository: its GitHub guide says the sync breaks and Lovable's support re-attaches the project. So Katrin asks support first, moves the repository, and nobody edits screens in Lovable until the sync works again. The Studio password and the secret key move from Aylin's password manager into IT's vault, where Katrin and Jonas can open them and every opening is logged. On Aylin's last day IT changes the Studio password and issues a new secret key. Lovable stays the tool for designing screens, but its changes now land on a separate working branch: in the project's GitHub settings she clicks Create branch in the branch picker and makes lovable-work the branch Lovable edits. Only the release page below merges a change into the main branch, which staging builds from.

Build it: staging and releases (90 min). One snag comes first. The app from T06-L04 · Put Your Team App on the Organisation's Own Database, and Prove You Can Restore It has the Supabase address and key fixed into it when it's built, so a build made for staging would talk to the staging database even in production. Katrin asks Lovable once to change that: when the app starts, it reads the address and the publishable key from a small file, config.json, that the server hands out next to it. Now one build can serve both copies.

In Dokploy she creates two applications. reorder-staging builds from the repository's main branch, on its own address, and, with Deployments → Rollback Settings switched on, pushes each build to the registry, labelled with the Git commit it came from (the ID Git gives every saved change). reorder in production doesn't build at all: its source is an image in the registry, and a release sets which label it runs. Each application gets its own config.json as a file mount (Advanced → Volumes) in the folder the app is served from, pointing at the staging or the live Supabase. A release has four steps, written on one page:

  1. Merge the change into the main branch. Dokploy builds it and deploys it to staging.
  2. Run the role test sheet from T06-L04 · Put Your Team App on the Organisation's Own Database, and Prove You Can Restore It against staging, as each role.
  3. If a data model change is in it, apply it to production first, and only as an add.
  4. Deploy the build that passed, by its label, to production. Watch the sign-in monitor for ten minutes.

The delivery date field goes out this way the following week. The model change adds the field; the old list still works without it; then the new screens follow.

Build it: the rollback drill (30 min). On staging she deploys a deliberately broken build, a list that shows nothing. Jonas, reading only the page, uses Dokploy's rollback to the previous build. The list is back in 70 seconds. They time the same step on production during a quiet hour with a harmless change, and it takes 90 seconds. The page gets a line: "Rollback puts back the screens, not the data model. If the release added a field, leave the field; the old screens ignore it."

Build it: outside checks (45 min). Four Uptime Kuma monitors, all posting to the Department apps channel:

  • an HTTPS check on the app's address, with a warning when the certificate has less than 14 days left;
  • a check on the health address of Supabase's sign-in service, which answers while sign-in works; the publishable key goes in the monitor's request headers;
  • a sign-in check. A push monitor is an address that Uptime Kuma expects to be called on time, and it alerts when a call is missing. Every five minutes a small job on IT's monitoring server signs in as the test account monitor-lab, asks for its test request TEST-R-01, and calls the push address only when the request comes back. The account can read that one request and nothing else;
  • a second push monitor that IT's nightly backup job calls when the dump has reached the backup server; no call within 24 hours, and the channel hears about it.

Build it: the year plan and the access review (45 min). One page, with dates: Supabase's monthly releases in IT's maintenance window, on staging first; the switch to the new kind of keys in November, well before the old ones are retired; PostgreSQL's next major version in the spring, which needs a dump and restore, so it's paired with the restore rehearsal; Lovable and registry costs reviewed in January; a restore rehearsal in March and September. Every quarter Katrin exports the members table, every account with its group and role, compares it with the institute's leaver list and with each group's members, and asks each group leader to confirm. The first review removes eleven accounts of people who have left.

Understand it: the builder-has-left test (half a day in February). IT disables Aylin's accounts for a day. Jonas, alone with the folder, releases a text change, rolls it back, and restores last night's backup to the test server, then runs the role test sheet against it. He gets through all three. He stops once, at the restore: the folder says to take the database password from the vault, but not which entry. The folder gets the entry name. Aylin's accounts are closed for good in March.

What it taught Katrin: the Friday outage looked like a Lovable problem. It was a missing staging step, and a builder who was the only way back.

Company: three apps and a backup that wasn't

Structure it (20 min). Tobias writes: "Three apps on one Supabase: demo kits, loaner instruments, service visits. Every change is tested on staging, every night's backup is proven to have arrived, and finance can show the auditor who had access to customer data."

Understand it (60 min). The failed rehearsal is the first thing on his list. The backup job wrote to the company's S3-compatible storage, a common kind of file storage for backups, with a key that expired after twelve months. Every night the job failed, and its failure message went to an old shared mailbox. The server's view had been green all along.

He also finds that each of the three apps was released differently: one through Dokploy, two copied by hand by a consultant. Back to Structure it: "One release path for all three apps. A backup counts only when the monitor has heard from it. Keys for backups and the registry have renewal dates in the year plan."

Choose tools and Build it (2½ hours). Dokploy for all three apps, each with staging and production. The backup job calls an Uptime Kuma push monitor only after it has checked the file on the storage. The storage key's expiry date goes into the year plan, with a reminder a month before. People sign in to Supabase with their company accounts through Microsoft Entra ID, so his quarterly access review compares the members table with Entra ID groups, the company's list of who belongs where, rather than with names. The data protection officer gets the review's result each quarter, and the finance lead files it with the procedure documentation from T05-L05 · Keep Your Automations Running for Months, and After You Leave.

The auditor's questions go back a year. The change history from T06-L04 · Put Your Team App on the Organisation's Own Database, and Prove You Can Restore It lives in the database, so every quarter its export for the three apps goes into the finance archive, as the works council agreed: for audits and fixing errors, not for assessing staff.

Understand it: the rehearsal again. In the next rehearsal, Svenja from logistics restores all three apps' data to a test server. It takes 1 hour 40 minutes, inside the two hours agreed with the head of sales. One app's screens fail against the restored data, because its build on the test server was older than production's. The release page now says: "Restore with the build label that production runs, from the registry."

In both cases the fix that mattered most was cheap and a little dull: a staging copy, a monitor that hears from the backup, and a deputy who did everything once without the builder.

What goes wrong

Publishing from the builder straight to production. Symptom: a change looks fine in the editor's preview and breaks the app for everyone. Fix: the AI builder's changes reach production only through the repository, staging and the role test sheet.

Building again for production. Symptom: staging passed, production fails, and the two builds differ. Fix: deploy to production the exact build that passed, by its label from the registry, and keep the database address in a settings file outside the build.

A rollback that loses data. Symptom: to undo a release, someone restores last night's database and wipes today's orders. Fix: change the data model in two steps, add first and remove later, so the previous build works on today's data.

Monitoring from inside only. Symptom: the server shows green while nobody can sign in. Fix: outside checks that sign in as a test account and look for a known test record.

Backups nobody hears from. Symptom: a restore rehearsal finds weeks of missing backups. Fix: the backup job reports to a push monitor after it has checked the file, and backup keys have renewal dates in the year plan.

Updates that change under you. Symptom: an update changes a setting or retires a kind of key, and the app or a monitor stops working. Fix: read the changelog, apply each update on staging first, and put announced retirements and licence renewals in the year plan.

The builder is the only way in. Symptom: the repository, the admin account or the registry password belongs to one person. Fix: organisation accounts, passwords and keys in IT's vault and changed when someone leaves, and the builder-has-left test before anyone leaves.

Do it yourself (6 hours, over a month)

  1. Structure it (30 min). Write how the app must run: who depends on it, how fast a bad release must be undone, how much data you may lose.
  2. Understand it (90 min). List everything the builder does and every account the app depends on. Mark what exists only in one head or one personal account. Check how far behind the current release you are and which kind of keys the app uses. Rewrite your sentences.
  3. Choose tools (20 min). Decide the release path (Dokploy or what IT runs), the registry, the monitor, and the update rhythm.
  4. Build it: ownership and staging (90 min). Move the repository and admin accounts to the organisation. Have the app read its Supabase address from a settings file, set up staging and production in Dokploy, and write the four-step release page.
  5. Build it: rollback and monitors (75 min). Run the rollback drill on staging and once, harmlessly, on production. Set up the four outside checks, alerting a team channel.
  6. Build it: year plan and access review (45 min). Put updates, licences, key renewals and restore rehearsals on dates. Run the first access review.
  7. Understand it: the builder-has-left test (half a day). Disable the builder's accounts for a day and let the deputy release, roll back and restore from the folder. Fix every gap.

Exit check

What you hand in: a handover folder for one app that many people depend on, with:

  • the release page with staging, the role test sheet and the four steps;
  • a rollback record from a drill: the build labels, the time taken and the check afterwards;
  • the monitor list: address, sign-in with a test record, backup arrival and certificate, all alerting a team channel;
  • the year plan with updates, licences, costs, key renewals and restore dates;
  • the latest access review, confirmed by the data owners;
  • a restore record from the last six months.

It passes when a deputy, with the builder's accounts disabled for the day, releases a change through staging, rolls it back and restores last night's backup to a test server from the folder alone, and the role test sheet passes on the restored copy.

Rule to remember

Change through staging, go back by build, and hand over before you have to.

Details for experts

Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.

WhatDetailsWhat it means for you
DokployVersion 0.30.7, released 18 September 2026; free to self-host. Dokploy Cloud manages your servers for $4.50 a month per server (Hobby) or from $15 a month (Startup).Self-hosting fits when IT runs the server anyway.
Dokploy rollbacksTwo ways: automatic rollback by Docker Swarm (Docker's multi-server mode) when the new version fails its health check during deployment, or registry-based rollback, which pushes every build to a registry and can return to any earlier one.Use the registry kind; keep enough builds in the registry.
Dokploy backupsDatabase backups on a schedule written in cron syntax (the standard way to write "every night at 02:00"), stored in S3-compatible buckets, with a Test button.Test once, then let the push monitor confirm every night.
Supabase releasesStable snapshots of the self-hosted Docker setup about once a month. update.sh pulls the latest self-hosted/v* release and merges it over your files; the self-hosted changelog lists what changed. Single containers can be moved to another version on their own, but compatibility isn't guaranteed.Update the whole setup, on staging first.
Supabase keysOlder anon and service_role keys are being retired by the end of 2026. On self-hosted installs the new publishable and secret keys start empty in .env, so only the older keys work until you generate them; utils/add-new-auth-keys.sh --update-env generates them.Switch on staging, then production, with a date in the plan.
Supabase healthGET /auth/v1/health with the publishable key in the apikey header returns the sign-in service's version.A cheap outside check that Supabase answers.
PostgreSQL versionSelf-hosted Supabase runs Postgres 15 by default; the cloud may run 17. Dumps from a newer version may not load into an older one.Pair major upgrades with a restore rehearsal.
Uptime KumaVersion 2.5.5. Monitor types include HTTP(s), HTTP(s) keyword, Push and Docker container. More than 90 notification services, among them Teams and Slack.A push monitor, fed by your sign-in job, is your sign-in check.
Lovable and GitTwo-way sync with repositories on github.com on all Lovable plans; GitHub Enterprise Cloud and Server only on Lovable's Enterprise plan. Transferring the repository breaks the sync until Lovable's support re-attaches it. VITE_ settings are fixed into the app at build time.Start the repository in an organisation account; read Supabase's address at start, not at build.
Two-step data model changesOften called expand and contract: add fields and tables first, remove old ones in a later release.Keeps the previous build working, so rollbacks stay safe.

Further reading and tools

Next books

Tools

  • Dokploy: Taught. Staging and production, builds in a registry, rollbacks, scheduled backups.
  • Uptime Kuma: Taught. Outside checks and push monitors.
  • Supabase: Taught. Updates, key changes, health check and access review.
  • Lovable: Taught. Screen changes that now go through the repository.
  • Gitea: Catalogued. A Git server with a built-in registry, if your organisation runs its own.