T06-L05

Build apps · Operator

Owning and operating your app

The booking tracker from T06-L04 now has a real API, data-layer permissions, a reviewed schema path, and a restore that somebody has actually performed. That is not yet an operated service. Its public route may still depend on a builder platform, its deployment may exist only in the author's memory, and its domain,...

Level
OperatorLevel 5 of 5
Curriculum position
Family 2 · Track 06
Reading time
120 minutes
Reading progress
0%Time on this book
Last revised
Sep 5, 2026

2. The builder is leaving in three weeks

The booking tracker from T06-L04 now has a real API, data-layer permissions, a reviewed schema path, and a restore that somebody has actually performed. That is not yet an operated service. Its public route may still depend on a builder platform, its deployment may exist only in the author's memory, and its domain, provider account, alerts, and secrets may still lead to one person.

That person is leaving. Alternatively, the builder platform has changed its price or export terms. In the Lab framing, colleagues need the synthetic PCR booking tracker on an institute-controlled server. In the Company framing, the same shared-equipment tracker must run on an organisation-controlled rented EU VPS. The records, tests, and release method are the same; the accountable owners and approved hosting boundary differ.

Your job is not merely to make the page appear on another machine. You must export a reproducible release, pass it through staging, promote an identified artifact, observe it, roll it back on command, and leave enough verified knowledge for a substitute operator. You will rehearse with synthetic bookings and disabled outbound integrations. The final evidence is one handover document containing the rollback record and the result of an "author has left" test.

3. After this you can

  • Deploy an exported app on infrastructure controlled through organisational accounts.
  • Separate staging and production by identity, data, secrets, routes, and release authority.
  • Promote an immutable application artifact and reviewed configuration rather than rebuilding by hand.
  • Detect and roll back a bad release using declared signals, a retained target, and a rehearsed procedure.
  • Monitor user reachability, application health, backup jobs, resource pressure, and certificate expiry without leaking sensitive data.
  • Hand over architecture, ownership, credential references, release steps, incident actions, and recovery duties to another authorised person.

4. Prerequisites

  • T06-L04 · Real data behind it, including its Directus/PostgreSQL backend, migration path, external backup, restore record, and cross-group permission tests.
  • T11-L04 · Your own AI server, for provider ownership, private service networks, TLS, restricted administration, staged releases, and external port verification. The workload here is the tracker, not an AI model.
  • An organisation-owned source repository, provider tenant, domain, DNS zone, and billing route. A personal account is not an acceptable production owner.
  • One approved Linux host or small cluster, current supported Docker tooling, and either an approved Dokploy installation or an equivalent reviewed deployment control plane.
  • Distinct staging and production names, databases, storage, service identities, secret references, and ordinary test accounts.
  • A named service owner, primary operator, substitute operator, data owner, security contact, and provider/billing owner.
  • An external uptime-check location and an approved alert destination that at least two people can access.
  • About 120 minutes in an approved maintenance window for a synthetic deployment and rollback rehearsal.

Use only invented users, groups, resources, booking purposes, credentials, domains reserved for documentation, and disposable databases in this exercise. Do not clone production data into staging. Do not place provider tokens, SSH keys, passwords, database dumps, Directus tokens, private hostnames, or alert destinations in Git, command history, screenshots, or the handover document. A European VPS location is one input to a hosting decision; it does not by itself prove that support, backups, logs, subprocessors, or data transfers meet organisational requirements.

5. The idea in one page

Operating ownership means that authorised people can change and recover the service without a personal account or unwritten step:

organisation-owned source + reviewed deployment declaration
                         |
                         v
             build once: image@sha256 digest
                         |
             +-----------+-----------+
             |                       |
             v                       v
 staging route + identity      production route + identity
 synthetic database            approved database
 staging secrets               production secrets
             |                       |
       release checks          health + user journey
             |                       |
             +---- promote IDs ---->+---- alerts ----> on-call roles
                                             |
                              trigger -> known-good release

Control is an inventory, not a server invoice

Infrastructure you control can still be rented. Control means the provider tenant, repository, domain, deployment tool, backup store, and alert channel belong to the organisation; access is individual and recoverable; exports use documented formats; and a second authorised operator can act. Self-hosting transfers work to you: operating-system updates, firewall policy, control-plane security, capacity, backup, monitoring, incident response, and end-of-life replacement all need owners.

Dokploy can provide a convenient control plane on a Hetzner Cloud server, but neither product becomes the service owner. Keep the Dokploy administrator interface on an approved administrative path. Do not make port 3000, SSH, Docker, PostgreSQL, Directus, or a metrics dashboard publicly reachable merely because installation or troubleshooting is easier. Public users should reach only the HTTPS application edge. Provider and host firewalls should agree about that boundary.

Staging is separate authority

Staging is not production with a different label. It has a different hostname, database, object storage, credentials, cookie scope, service identity, and access group. It uses synthetic data and has email, payment, calendar, webhook, and scheduled side effects disabled or redirected to approved sinks. A staging credential cannot read or alter production. Production secrets are unavailable to staging builds and operators who do not need them.

Build one immutable app image in reviewed automation. Record its source commit, build record, image name, and digest. Test that exact digest in staging, then promote the digest with the reviewed deployment declaration. Do not rebuild the same version label for production. Configuration is also part of the release: record the configuration revision, migration set, feature flags, and secret references, never secret values.

Rollback is a state transition

"We can revert Git" is not a rollback plan. Before release, identify a known-good application digest and compatible configuration revision that are still retrievable. State the trigger, decision owner, command or approved control, and verification. A rollback has succeeded only when the running service reports the old identity and health, the synthetic user journey passes, denials remain denied, and the error signal recovers.

Database changes complicate reversal. Prefer backward-compatible expansion: add nullable fields or parallel structures, deploy code that understands old and new shapes, migrate safely, and remove old shapes in a later release. Do not automatically restore yesterday's production database to reverse application code; that can erase valid bookings created since the backup. If a migration is not backward compatible, block the release until a specific restore or forward-fix plan, data-loss decision, maintenance window, and owner have been approved.

Monitoring serves a decision

A green container is not the same as a usable app. Observe four layers: external HTTPS reachability and certificate validity; a shallow health endpoint; a synthetic user journey using non-sensitive records; and internal saturation or failures such as CPU, memory, disk, restart count, database connections, queue depth, backup age, and error rate. Every alert needs a threshold, duration, recipient, first action, and escalation path. Logs should carry timestamp, environment, release ID, request correlation ID, route class, status, and duration, but not credentials, session cookies, booking purpose text, or personal data.

6. The worked example: release the booking tracker and take it back

The running project remains the bookings app and Directus/PostgreSQL data layer from T06-L04. The Lab labels its synthetic resource PCR-SYN-01; the Company labels it EQUIP-SYN-01. Both use groups SYN-CEDAR and SYN-ORBIT, with all outbound integrations disabled. The example uses Dokploy on an approved VPS because it makes source, deployments, domains, and logs visible, but the evidence is deliberately portable to another control plane.

Freeze the portable service definition

Export the builder project into the organisation's repository. The export must include readable source, lockfiles, a reproducible production build, database migrations or Directus schema references, a health endpoint, tests, a container definition, and deployment instructions. It must not rely on a private builder plugin, a hidden data store, or a personal deployment token.

Create an ownership inventory before provisioning:

Service: Synthetic Booking Tracker
Lab purpose: practise PCR instrument booking operations
Company purpose: practise shared-equipment booking operations
Repository / owners: [organisation location] / [primary and substitute roles]
Provider tenant / billing owner: [organisation tenant] / [role]
DNS zone / recovery contact: [controlled zone] / [second authorised role]
Dokploy project / administrators: [project] / [individual accounts or group]
Staging route: tracker-staging.example.org
Production route: tracker.example.org
Public route: HTTPS 443 to application edge only
Administrative route: [approved VPN or source] to SSH and Dokploy UI
Private routes: database, Directus, Docker API, metrics
Source data: synthetic only for rehearsal
Backup / restore evidence: [T06-L04 controlled record]
Alert channel / recipients: [approved reference] / [two roles]

The example.org names are reserved examples. Replace them only with approved organisational names when actually deploying. Confirm provider support access, server and backup regions, retention, deletion, and offboarding requirements. Attach the provider firewall before application installation. Dokploy's installer may require ports 80, 443, and 3000 to be available locally; that does not require the administrator UI on 3000 to be open to the Internet. Follow current official installation guidance and the organisation's reviewed hardening path rather than pasting an unaudited installer command into a production host.

Declare two environments

In Dokploy, create one project with clearly separate staging and production environments, or two projects if organisational policy requires stronger separation. Configure different domains, databases, persistent volumes, credentials, and environment-scoped deployment identities. Ensure each environment receives only its own secret references.

Keep a secret-free release declaration in the repository:

service: booking-tracker
release: r17
source_commit: "[full reviewed commit]"
app_image: "registry.example.org/booking-tracker@sha256:[reviewed-digest]"
config_revision: "booking-config-17"
drill_config_revision: "drill-off-v1"
migration_set: "bookings-17-expand-only"
health_path: "/healthz"
smoke_fixture: "booking-synthetic-v3"
rollback:
  release: "r16"
  app_image: "registry.example.org/booking-tracker@sha256:[known-good-digest]"
  config_revision: "booking-config-16"
  drill_config_revision: "drill-off-v1"
  migration_compatibility: "r16 reads schema 17"

Bracketed values are placeholders and must be replaced with reviewed values. The repository domain shown is also an example. Store runtime secrets in the approved deployment secret mechanism. The application receives a database credential scoped to its environment; it does not receive a provider token, DNS administrator credential, or Dokploy administrator credential. Pin base images and application images by reviewed digest. Retain the previous digest at least through the observation and rollback window.

Create booking-synthetic-v3 through the ordinary staging application path. It contains one Cedar booking, a read-only Cedar fixture with ID SYN-ROLLBACK-PROBE, no real names or free text, and an expected Orbit denial. Keep the checks in the repository:

Health: GET /healthz -> 200; body identifies environment=staging and release=r17
Allowed journey: Cedar test user reads PCR-SYN-01 or EQUIP-SYN-01
Denied journey: Orbit test user cannot read the known Cedar booking ID
Write journey: Cedar creates SYN-ROLLBACK-01, then reads it
Public journey: logged-out request receives the designed denial
Outbound journey: no email, calendar event, webhook, or payment occurs

Do not make /healthz reveal hostnames, dependency credentials, stack traces, or database contents. A shallow check can report application readiness and release ID. Run a separate authenticated deep check where policy permits, or let the synthetic journey prove the dependencies.

Release to staging

Configure Dokploy to build from the reviewed repository or, preferably, deploy the image already built by reviewed automation. Restrict registry pull credentials to the required repository. Make deployment automatic only to staging; require the named production approver for production.

Before deploying, record r16 as the known-good target and prove that its image digest is retrievable. Back up the staging database if the rehearsal changes its schema. Validate the deployment declaration and migration compatibility. Deploy r17 to staging, then capture these results without secret-bearing output:

curl --fail --silent --show-error \
  https://tracker-staging.example.org/healthz

curl --silent --show-error --output /dev/null --write-out '%{http_code}\n' \
  https://tracker-staging.example.org/app

The first response must identify staging and r17 according to the app's documented JSON contract. The logged-out result must equal the designed denial or redirect; record the expected status before testing. Do not use --insecure. Inspect the certificate name and expiry, the Dokploy deployment result, resolved image digest, application restart count, and logs. Run all five fixture checks with ordinary staging accounts and confirm the staging build cannot reach production data.

Promote only when the source commit, image digest, configuration revision, migration set, and test results match the release record. A reviewer must compare identifiers, not accept a green badge. For a live service, choose a maintenance or low-risk window, announce ownership, confirm the backup status and rollback target, and define a short observation period. For this course rehearsal, production is an isolated production-like environment containing only the synthetic fixture.

Introduce one safe, observable failure

Do not corrupt a database, delete a volume, block administrator access, expire a certificate, or test against a service people rely on. In the isolated production-like environment, deploy candidate r18-drill, which is the same safe code base with a reviewed test configuration that makes only one marked read of SYN-ROLLBACK-PROBE return a controlled 503. Its health response must still reveal release=r18-drill, and it must not write data or trigger outbound actions.

Make that behaviour reproducible rather than asking an operator to improvise a firewall rule. Commit a small request guard and two secret-free configurations with the application. The enabled configuration for candidate r18-drill is:

{
  "enabled": true,
  "allowedEnvironments": ["staging", "production-like"],
  "release": "r18-drill",
  "method": "GET",
  "path": "/api/bookings/SYN-ROLLBACK-PROBE",
  "markerHeader": "X-Rollback-Drill",
  "markerValue": "r18",
  "status": 503
}

Call this reviewed file config/r18-drill.json. The normal config/drill-off.json has the same keys but sets enabled to false, release to r17, and contains no active marker value. Select the file in the deployment declaration, for example with drill_config_revision: "r18-drill-v1"; do not edit it in the control-plane UI. The marker is a selector, not a credential. Authentication and Cedar permission checks still run before the guard, and both allowed environments must contain synthetic data and disabled outbound actions.

Implement the guard in the app's request layer. This Express-style example is deliberately small enough to test and port; place it after authentication but before the ordinary booking-read handler:

const drill = require(process.env.DRILL_CONFIG_PATH);
const environment = process.env.DEPLOYMENT_ENV;
const release = process.env.RELEASE_ID;

app.use((req, res, next) => {
  const selected = drill.enabled
    && drill.allowedEnvironments.includes(environment)
    && release === drill.release
    && req.method === drill.method
    && req.path === drill.path
    && req.get(drill.markerHeader) === drill.markerValue;

  if (!selected) return next();
  return res
    .set("Cache-Control", "no-store")
    .set("X-Release-ID", release)
    .status(drill.status)
    .json({ error: "rollback_drill", release, scope: "synthetic-booking-read" });
});

app.get("/healthz", (_req, res) => res.json({
  status: "ok", environment, release
}));

Fail application startup if the configuration cannot be parsed, if an enabled file names anything except the fixed synthetic path, if its environment allowlist contains anything except staging and production-like, or if its release does not exactly match the runtime value. Add automated tests showing that all six selectors are required, the selected request performs no booking mutation, /healthz stays 200, and the response contains the same release in both X-Release-ID and JSON. This prevents a misspelled or over-broad rule from becoming the drill.

Before promotion, prove the mechanism in staging with the dedicated Cedar monitor identity. Keep its bearer value in the shell's approved secret injection, not in the command or evidence. These commands create independently comparable header and body files, with the status printed separately:

base="https://tracker-staging.example.org"
auth="Authorization: Bearer ${SYNTHETIC_MONITOR_TOKEN}"

curl --silent --show-error -H "$auth" -H 'X-Rollback-Drill: r18' \
  --dump-header drill-headers.txt --output drill-body.json \
  --write-out '%{http_code}\n' \
  "$base/api/bookings/SYN-ROLLBACK-PROBE"
# expected: 503; body has error=rollback_drill and release=r18-drill

curl --fail --silent --show-error -H "$auth" \
  "$base/api/bookings/SYN-ROLLBACK-PROBE"
# expected: 200 without the marker; fixture is unchanged

curl --fail --silent --show-error "$base/healthz"
# expected: 200 with environment=staging and release=r18-drill

Use the equivalent production-like hostname only during the approved drill. Record the HTTP status, response release, health release, deployment ID, and UTC time. Do not archive the authorization header. A second operator or external probe must run the marked request independently of Dokploy; application logs or a control-plane badge alone are not break evidence.

Define the rollback trigger before deployment:

Trigger: two consecutive synthetic booking-journey failures within three minutes
Decision owner: service owner; operator may act immediately during this declared drill
Target: r17 + booking-config-17 + bookings-17-expand-only
Data action: none; r17 is compatible with the current schema
Maximum drill recovery objective: 10 minutes from trigger to verified service
Stop condition: unexpected real traffic, data mutation, lost admin path, or secret exposure

Deploy r18-drill through the same controlled path, setting RELEASE_ID=r18-drill, DEPLOYMENT_ENV=production-like, and DRILL_CONFIG_PATH to the immutable enabled file. Verify that the independent monitor sees exactly the scoped 503, while the same fixture read without the marker and /healthz both remain 200; both the error response and health response must identify r18-drill. Stop immediately if another route fails, either release identity differs, or the fixture changes. A failed container start is useful to test separately, but it does not prove rollback from a running application that gives users bad results.

Roll back and prove the resulting state

In Dokploy's deployment history, select the retained known-good r17 deployment or redeploy the exact recorded source and image digest using the current official rollback/redeploy mechanism. Do not rebuild r17, click an unidentified older entry, or edit production configuration by hand. Record the control used and its deployment ID. If the platform cannot select an immutable prior release, use the repository's reviewed deployment procedure to restore the declared r17 digest and booking-config-17.

Start the timer at the second failed synthetic check. After the control plane reports completion, verify independently:

  1. External HTTPS and certificate checks pass without bypasses.
  2. /healthz identifies the production-like environment and exact r17 release.
  3. The Cedar allowed read and write journeys pass with synthetic data.
  4. Orbit known-ID and logged-out requests remain denied.
  5. No outbound integration fired and no database restore occurred.
  6. Error rate and synthetic availability recover for the whole five-minute observation period.
  7. Logs show the release transition and no repeated crash, migration, authentication, or connection error.
  8. The independent marked probe now returns the ordinary successful fixture read, not the drill 503, and /healthz reports r17; this proves that the bad release and its enabled configuration both left service.

Repeat the same marked request pattern against the approved production-like base after rollback, writing to new post-rollback-headers.txt and post-rollback-body.json files so the drill evidence is not overwritten. Expect 200, then capture /healthz separately and expect release=r17. Compare the externally observed release values with the retained deployment record; do not treat a control-plane status alone as rollback proof.

Record timestamps in UTC, deployment IDs, expected and actual signals, elapsed time, operator, approver, and deviations. Link to restricted evidence rather than pasting sensitive logs. Keep r18-drill blocked from promotion and open a corrective item. A rollback that restores the page while weakening group permissions is a failed rollback.

Add monitoring that somebody will answer

Configure an external HTTPS monitor for /healthz and an authenticated synthetic monitor for the bounded booking journey. Use dedicated least-privilege synthetic identities and store their credentials in the monitoring secret store. Ensure monitors cannot approve bookings, administer Directus, or access production records beyond their isolated fixture. If approved production policy prohibits synthetic writes, use a read-only fixture whose lifecycle and exclusions are documented.

Add alerts for repeated external failure, elevated server errors, certificate expiry, host disk pressure, repeated container restart, database unavailability, and stale or failed backups. Tune thresholds from observed normal behaviour; a single transient probe should not wake an operator unless the service objective requires it. Test the route with a harmless test alert and acknowledgement. Record who receives it after hours, what the first safe diagnostic is, when to roll back, when to escalate, and where status communication occurs.

Monitoring data has a lifecycle too. Limit collection, redact request content and authorization headers, restrict dashboard access, define retention, and verify deletion. Do not attach full database queries or user-supplied booking purpose to alerts.

Run the "author has left" test

The original author now becomes silent: no hints, personal password manager, active browser session, or private notes. Give the substitute operator only their own approved accounts and the draft one-page handover. Ask them to:

  1. locate repository, provider project, DNS, Dokploy project, backup record, and alert dashboard;
  2. identify the running release and retained rollback target;
  3. acknowledge a test alert and follow the first diagnostic step;
  4. redeploy r17 to staging without changing its digest;
  5. run health, allowed, denied, and outbound checks;
  6. explain who approves production, rotates each secret, patches the host, restores data, and communicates an incident.

The author may stop unsafe action but may not supply a missing step. Record each block as a handover defect. Remove temporary access after the test, retain required evidence under policy, and have the substitute confirm that no shared credential was used.

7. What goes wrong

Every change is a production experiment

Symptom: a commit deploys directly to the public route, and staging shares production data or credentials.

Fix: separate authority, make staging synthetic, promote exact identifiers, require production approval, and block deployment when environment isolation cannot be demonstrated.

Rollback means rebuilding an old branch

Symptom: the old tag now produces a different image, or nobody knows which configuration and migration set belonged to it.

Fix: retain immutable image digests and versioned configuration, record compatibility before release, and verify the running post-rollback identity.

Application rollback destroys newer data

Symptom: the runbook restores an old database backup whenever code is reverted.

Fix: design backward-compatible migrations and roll back code without touching valid data. Treat database restore as a separately authorised recovery action with an explicit data-loss decision.

Users are the uptime monitor

Symptom: the container is green, but nobody notices failed login or cross-group errors until a colleague reports them.

Fix: combine external reachability, a synthetic user journey, denial checks, application errors, dependency health, and tested alert delivery.

The dashboard becomes a public back door

Symptom: Dokploy port 3000, SSH, PostgreSQL, Directus administration, or metrics are Internet-wide.

Fix: restrict administrative paths with provider and host controls, prefer an approved VPN or identity-aware route, and scan all server addresses externally after changes.

Credentials belong to the departing author

Symptom: domain renewal, provider recovery, deploy keys, backups, or alerts depend on one mailbox or password manager.

Fix: move ownership to organisational tenants, use individual access and groups, keep a controlled credential inventory of references only, and test substitute access before departure.

The runbook is a diary

Symptom: it says "restart as usual," contains obsolete screenshots, or works only from the author's configured laptop.

Fix: use exact locations, prerequisites, decision points, expected results, and stop conditions; then have a substitute execute it with clean authorised access.

8. Do it yourself: deploy, break, roll back, and hand over in 120 minutes

Minutes 0-12: choose Lab or Company framing. Confirm the environment is isolated, synthetic, and authorised for a failure drill. Name all owners, public and administrative routes, stop conditions, alert recipients, and the ten-minute drill objective.

Minutes 12-27: export the app into the organisation repository. Confirm source, lockfiles, container build, health contract, schema references, smoke tests, and deployment instructions exist. Scan source and built output for secrets. Record gaps rather than inventing hidden builder behaviour.

Minutes 27-42: create separate Dokploy staging and production-like environments with distinct domains, identities, secrets, data, and volumes. Keep administrative services private. Resolve and record the candidate and known-good image digests.

Minutes 42-57: deploy r17 to staging. Run certificate, health, Cedar allowed, Orbit denied, logged-out denied, synthetic write, and outbound-disabled checks. Compare source, image, configuration, and migration identifiers with the release declaration.

Minutes 57-70: promote exact r17 identifiers to the isolated production-like environment. Observe health, errors, restarts, database connectivity, and synthetic journey. Confirm the rollback image remains retrievable and schema compatibility is explicit.

Minutes 70-82: deploy the reviewed r18-drill failure configuration. Wait for the declared two failures, start the timer, and use the documented control to restore exact r17. Do not alter or restore the database.

Minutes 82-94: prove the post-rollback release ID, five-minute stable observation, allowed and denied behaviour, absence of outbound effects, and elapsed time. Save non-sensitive evidence references and mark deviations.

Minutes 94-105: configure or review external, journey, error, capacity, certificate, and backup-age monitoring. Send one harmless test alert, have the substitute acknowledge it, and verify escalation ownership.

Minutes 105-116: finish the one-page handover using the template below. The substitute performs the author-left tasks with individual access while the author remains silent.

Minutes 116-120: record pass, revise, or escalate; assign every gap; remove temporary identities; and confirm that evidence contains no secrets or real data.

9. Exit check

Deliver exactly one artifact: one completed one-page operations handover document with the rollback record embedded in it.

Use this compact structure:

SERVICE AND PURPOSE
Lab or Company framing; synthetic scope; service/data/technical owners

ONE-PAGE ARCHITECTURE
public HTTPS edge -> app -> Directus -> PostgreSQL; private admin and backup paths
staging and production names; repository, provider, DNS, Dokploy, backup, monitor references

CREDENTIAL INVENTORY (REFERENCES ONLY)
system; human or service role; approved store/group; rotation owner; revoke path

RUNBOOK
identify release; deploy to staging; checks; approve/promote; monitor; rollback; escalate
known-good release/image/config/schema compatibility; backup and restore-record references

ROLLBACK EVIDENCE
trigger and UTC time; bad deployment ID; target IDs; operator/approver; action used
health, allowed, denied, outbound, release-ID and five-minute observations; elapsed time

AUTHOR-HAS-LEFT TEST
substitute and date; own-access result; staging redeploy result; alert acknowledgement
blocked steps and owners; final decision: PASS, REVISE, or ESCALATE

It passes when the document fits on one normal page using concise references; names organisation-controlled locations and accountable roles; includes no credential values; distinguishes staging and production; identifies immutable bad and known-good releases; records a performed rollback with trigger, UTC timestamps, elapsed time, and post-state evidence; preserves data and permission checks; shows a substitute operator completed the author-left test using individual access; and ends with PASS, REVISE, or ESCALATE. It fails if the original author supplied an undocumented step, rollback rebuilt an unverified artifact, the database was casually restored, monitoring has no recipient, administrative ports are public, real data entered staging, or secrets appear in evidence.

10. Rule to remember

If only you can deploy it, you have not finished it.

11. Further reading & tools

Curriculum connections

Follow the authored paths

These explicit curriculum relationships complement the sequential Previous and Next links below.

Prerequisite books

Authored neighbours

Related canvases

Staging Production

staging-production.svg

Press Escape to close.

staging-production

Staging Production

Course canvas for Staging Production.Open full canvas

Continue the work

References from this book

Tools and current material are kept alongside the durable lesson, not mixed into it.

Tools in practice