Projects and deployments¶
A deployment is one running Open Meridian runtime in your cluster. Before it can do anything that involves the platform, it has to be registered there, in a project, and it has to prove it is the deployment it claims to be. This page explains the records the platform keeps for that, who may change them, and the one-time codes that carry a deployment from registration to its first sign-in.
The steps themselves are in Installing a deployment.
Projects¶
A project is the platform's unit of ownership: a set of people, each with a role, and the deployments they administer. Signing up and creating a project is free, and needs no company.
Projects and organisations
On screen it is a project. Underneath, and in the platform's API, the same record is an organisation. They are one thing with two names.
Members and roles¶
People join a project by invitation. An owner invites somebody by email and chooses their role when inviting them; the role is fixed at that moment, so a forwarded invitation cannot ask for more. The person joins by signing in with that address.
There are three roles, and each includes the one before it.
| Role | What it may do |
|---|---|
| Member | See the project and its deployments |
| Admin | Also manage deployments: register, rename, retire and return them to service, add and revoke keys, and issue codes |
| Owner | Also manage members: invite and remove people, and close the project |
Registering a deployment, and everything after it on this page, needs admin or owner. A project always has at least one owner: removing or demoting the last one is refused.
An owner may close a project once every deployment in it has been retired. Closing withdraws pending invitations and deletes nothing.
A role on the platform is not access to a deployment
Being an owner or admin of a project lets you manage the deployment's record on the platform. It gives you nothing inside the deployment: who may sign in there, and what they may reach, is decided by the deployment itself. See Access.
Deployments¶
Registering¶
Registering a deployment gives it a name and an identifier, DEP- followed
by 26 letters and digits. The name is for people and can be changed at any
time with Rename; the identifier never changes. It is what meridian up
--id is given, and it is the subject of every assertion the deployment ever
signs, which is why the page shows it with a Copy button rather than
asking you to retype it.
A deployment's row on the platform says where it is:
| Shown | Meaning |
|---|---|
| Needs a key before it can connect | Registered, with no key enrolled yet |
| Hasn't connected yet | A key is enrolled; the deployment has not called the platform with it |
| Connected / Last connected | It has called, and when it last did |
| Retired | Taken out of service; its keys were revoked |
Once connected, the row also lists what each component reported about itself: its version and whether it is serving.
Keys¶
A deployment proves who it is by signing each request with a private key. The key is generated by the conductor, inside your cluster, and the private half never leaves the conductor's volume. The platform holds only the public half, listed on the deployment with a fingerprint.
There are two ways a public key reaches the platform.
- Enrolment, the ordinary route. The install carries a one-time enrolment code instead of a key. The conductor makes its keypair, registers the public half using the code, and the code is spent. Nobody handles either half.
- Add a key, the recovery route. A person pastes a public key the deployment generated. It exists for rotation and for deployments that cannot reach the platform to enrol; to rotate, add the new key, then revoke the old one. The form refuses a private key outright.
Revoke removes a public key. The deployment can no longer sign in with it, and if it was the only key the deployment stops working with the platform until it has another. Because a revoked key is removed, a deployment left with no keys can be issued a fresh enrolment code and enrol again under the same identifier.
Compare the fingerprint
After enrolment, the first-run wizard shows the deployment's identifier and its key's fingerprint before it asks for anything. It must match the fingerprint on the platform. If it does not, somebody else spent your enrolment code: revoke that key, issue a fresh code, and enrol again.
Retiring and returning to service¶
Retire takes a deployment out of service. It revokes every key the deployment holds and expires every code outstanding for it, so a retired deployment cannot connect, cannot enrol a new key, and cannot redeem a code. Its history is kept. Retired deployments are hidden from the list until you choose Show retired, and the page always says how many are hidden.
Return to service brings it back with the same identifier. Its old keys do not come back — revoking them is what made the retirement real — so it enrols a new one.
Retiring is not the same as uninstalling. Removing the chart from your cluster leaves the platform believing the deployment exists; retiring it on the platform is what revokes its keys.
Deleting a deployment outright discards the record of what its keys signed. It is offered only where Open Meridian has enabled it for a project; retiring is the ordinary way out.
The one-time codes¶
Four codes carry a deployment through setup and recovery. They share one shape:
- Shown once. The platform keeps only a hash, so nobody can be shown the code again, including Open Meridian.
- Single use, and expires after a day.
- Issuing another expires the last of the same kind, so re-issuing after a mistake leaves nothing working that went somewhere it should not have.
- Refused for a retired deployment.
| Code | Offered | What it does |
|---|---|---|
Enrolment (ENR-…) |
While the deployment holds no key | Carried by the install, in MERIDIAN_ENROLMENT_CODE. The conductor spends it to register the key it generated. Refused once a key is enrolled |
| First-run | Once the deployment has connected | Opens the deployment's first-run wizard. Nothing in the wizard is open to whoever finds it until this code is entered |
| First-admin | Once the deployment has connected | Makes the first deployment admin, redeemed at the dashboard's /claim by somebody signed in. Refused once the deployment has any administrator |
| Password-reset | Once the deployment has connected | For a deployment that holds its own accounts: at its sign-in page, Lost your password? takes the code, the login of a local administrator, and a new password |
Why enrolment and first-run are separate codes: enrolling is a machine proving what it is, and first run is a person proving they are allowed to set it up. The other three are offered only after the deployment has connected because it is the deployment, over its own signed call, that presents them to the platform. The platform learns that a code was used and when, never who typed it.
The first-admin and password-reset codes are recovery paths. On an ordinary install the wizard names the administrators, and nobody needs either. See Reset a lost password.