Instances
One app. As many purposeful copies as the team needs. Production, staging, a customer-specific deployment or a demo from the same codebase, each with its own URL, configuration, data, access and release history.
Keep the code shared and the runtime separate. An app is the code. An instance is one running copy of it.
crm/prod crm/staging crm/client-a crm/client-b
The default instance is prod, so crm and crm/prod are the same target, and every command takes the app/instance form.
Every instance owns its operating context.
Each instance has its own:
- hostname;
- environment variables;
- access rule;
- services;
- named volumes and data;
- release history;
- logs;
- desired state: running or stopped.
A configuration change to staging does not change production.
A second environment is one command.
Create it first$ hub instance create crm staging $ hub deploy --name crm --instance staging
$ hub deploy --name crm --instance client-a
crm.acme.myhub.host crm--staging.acme.myhub.host crm--client-a.acme.myhub.host
Use instances wherever the software is shared but the context is not.
Production and staging
Test a release with separate configuration and data before promoting the code through a normal deploy.
One customer, one instance
Give each customer a separate URL, environment and data volume without a separate repository.
One employee or team
Run isolated copies of an operational tool for people who need the same app with different data.
Temporary demos
Create a named demo, stop it when the event ends and remove it when it is no longer useful.
Instances can follow different branches. Production can watch main while staging follows another branch, or deploys only when someone asks.
Each connected instance records its repository, branch, subfolder, last deployed commit and whether auto-deploy is on.