App → Environment → Instances Hierarchy

Everything in Wakastart is organized around the App.

textCopy
App "Example"
├── Architecture (the "blueprint" — what you describe once)
│   ├── Repositories       (the Git repos)
│   ├── Services           (ServiceDefinitions)
│   ├── Dependencies       (DatabaseDefinitions, StorageBucketDefinitions)
│   └── URLs               (HttpRoutes, subdomains, custom domains,
│                           domain apex, App-scope redirects)
│
├── Builds                 (Docker images built from the code)
│
└── Environments            (concrete instances — dev, staging, prod...)
    ├── example-dev
    │   ├── ServiceInstances    (one per ServiceDefinition)
    │   ├── DatabaseInstances    (one per DatabaseDefinition)
    │   ├── StorageBucketInstances
    │   ├── Deployments
    │   ├── Variables & secrets
    │   ├── Real URLs
    │   └── Monitoring
    └── example-prod
        └── ... same

Why this separation between Architecture and Environment?

The Architecture describes your app once: "I have a Node.js backend, a PostgreSQL database, an S3 bucket".

Environments instantiate this architecture as many times as you want: dev, staging, preprod, prod, test-branch...

Each environment has its own:

• databases (each with its own isolated DB),
• storage buckets,
• URLs (app.dev.example.com in dev, app.example.com in prod),
• configuration variables,
• secrets,
• deployments.

So you can test in dev without touching production.