Design derivation
From the desired operating experience to one shared startup path.
Bartl did not begin with a new orchestrator. It began with the question of how a stateful application would have to behave so that recovery no longer remained a rarely rehearsed special case.
Complexity does not disappear. It is placed into an executable contract once instead of being demanded from a person again at every startup.
The desired experience
Think iPhone.
An application should return to service as naturally as a phone does. The user does not describe the internal operation. The system recognizes the situation it finds and follows the admissible path.
New device without existing state
-> initialize
Replacement device with a backup
-> restore
Newer system with older state
-> migrate
Incompatible state
-> stop safely
A mental model, not architecture evidence
Bartl neither reproduces the internal architecture of an iPhone nor inherits its closed operating environment. The image sets an expectation for ease of use. Different starting situations should not require different runbooks. Bartl's concrete technical answer emerges only from the observations below.
The journey
The pattern condensed through several operating questions.
The form changed while the core remained stable. Installation, change, and recovery should not be treated as separate worlds.
-
2022
The opening question
How would a businessperson design IT today if simplicity, dependable operation, and recovery were considered from the outcome backwards? The iPhone supplied the mental model.
-
2023
The operating objective
Production changes should become reproducible, inspectable, and independent of the person executing them. Fewer distinct procedures became a quality attribute.
-
2025
The recurring pattern
Operating customer-specific stateful stacks exposed the same decision repeatedly. Existing state, a backup, and versions determine the next step.
-
2026
The open cut
The application startup path was described as one technical contribution to Bartl and separated from its original product context through an executable WordPress reference.
Five observations
The design starts with conditions that cannot be planned away.
-
Value is created in production.
Builds, artifacts, and plans are means. Only an accessible and functionally correct application provides the intended service.
-
Change is inevitable.
Software, data formats, dependencies, and target environments do not remain at the same version forever.
-
Errors are inevitable.
Good prevention cannot eliminate outages, incomplete changes, or damaged inputs completely.
-
Rare manual procedures are not dependable.
A recovery runbook used only during an emergency drifts away from the production path that is exercised regularly.
-
Every additional link has a cost.
Every handoff between intent and result adds cognitive load, failure surface, and side effects that are harder to see.
Design pressure
Four requirements follow from the observations.
- Failures cannot be prevented completely.
- Recovery must be part of the design.
- A rarely used recovery path drifts.
- Routine changes should exercise reconstruction too, for example through a replacement installation from a backup.
- Manual precision does not scale.
- The path must be executable, inspectable, and reproducible.
- Additional control layers lengthen the chain of effect.
- The mechanism must remain close to the application and its state.
The design objective
Perform state changes and recovery with as few distinct mechanisms as possible. Normal startup and recovery must not develop separate truths.
The discovery
How the application starts.
You install or start the application. It works out what needs doing:
- If its data is already there, it uses it.
- Otherwise, it restores the latest backup.
- If no backup store is configured, or there is no backup yet, it starts with the application's initial data.
- If the software is newer than the data, it performs the necessary update.
You do not have to choose or manually perform those internal steps.
For routine upgrades, we can install the newer version as a replacement rather than change the running installation. The replacement restores the backup and updates the data through that same procedure. Each such upgrade therefore also exercises recovery.
This is an operating choice, not a different application mechanism: we select the version and where it should run; the application determines the steps.
Choosing a replacement changes the destination and requires switching service to it, but does not introduce another initialization/recovery interface.
until serving():
local = observe_local_state()
if local.exists:
engine version vs local.version:
equal: serving()
engine >: migrate(local)
engine <: abort("downgrade")
else:
backup = observe_backup()
if backup.valid: restore(backup)
else: init()What follows directly
The shared path changes the shape of operations.
- fewer distinct operating procedures and lower cognitive load
- backups that are checked technically before use
- migrations whose decision and result remain observable
Composition
The startup mechanism and multiplied single tenancy solve different problems.
Multiplied single tenancy means one stack per customer, repeated from the same blueprint. Isolation initially multiplies the operating objects. The startup contract makes their application and state lifecycle repeatable. Fleet management can coordinate that repetition; this topology is not a prerequisite for Bartl.
Single tenancy
Isolation
- one customer and one state domain per stack
- separate failure and compliance boundaries
- additional infrastructure and operating objects
Bartl startup mechanism
Repeatable lifecycle
- the same startup contract for every stack
- one path for initialization, restore, and migration
- no tenant isolation and no fleet control
Fleet management
Consistency across the fleet
- control versions and rollouts across stacks
- make deviations and results visible
- avoid manual care of every individual stack
Together they can form a dependable operating model.
Separate stacks can provide a smaller blast radius, individual data and compliance boundaries, and customer-specific releases and migrations. The shared startup contract makes their lifecycles repeatable. Fleet management can coordinate versions and rollouts; its benefit must justify its costs and shared authority risks.
The shared startup path removes neither the resource cost nor the operating work of additional stacks. It reduces distinct procedures. How repetition is coordinated depends on scale and operating requirements, not a universal fleet-management obligation.
Clean separation
The derivation explains why. The application contract specifies one contribution.
Bartl covers application, infrastructure and responsibility for the complete service. The canonical framing is in README.md and its linked philosophy. This page explains the startup mechanism; the technical spec presents its application contract rather than defining all of Bartl. Target provisioning, safe activation and the complete recovery process require additional executable procedures and their own evidence.
Read the canonical framing and contracts