Appearance
🖥️ shellno session yet
Chapter 1 — The cast
What we are going to do
Start from an empty machine and finish with a real agent process enrolled into a mesh, reporting telemetry the platform accepts.
Everything in between is the path a platform actually takes to get there: tenants, access, a provisioning catalog, a cloud resource, and the network that reaches it.
Nothing is mocked. The cloud is emulated locally, but every control-plane call, every authorization decision, and every audit entry is the real implementation.
Four words to hold on to
Domain — a tenant. Hard isolation boundary. Its own identities, its own audit log, its own mesh address range.
Project — a unit of work inside a Domain. Owns Resources and gets a slice of the Domain's network range.
Resource — a thing that was provisioned. A bucket, a node, a database. Carries a lifecycle from Pending to Ready.
Node — a Resource that joined the mesh and can be reached.
Access is a relation, not a role
plexsphere answers three questions, and it answers them the same way every time:
- Can this subject do this to that resource?
- What may this subject reach?
- Who may reach this resource?
There is no role column on a user row. Access is a graph of relations — a user is a member of a group, that group is a maintainer of a project — and every check walks that graph.
Chapter 5 is where this stops being an abstraction.
Everything is written down
Every state change lands in a per-Domain audit log, hash-chained so tampering is detectable rather than merely discouraged.
Chapter 4 writes into it and reads its own writes back out. Chapter 4 also verifies the chain.
This is not a feature we bolt on for compliance slides. It is the same path every command in this demo already took.
The seeded world
make dev plants a fixed cast. Nothing in this demo creates these — they are simply there:
| Domain | What it is for |
|---|---|
acme-corp | Our home tenant. Almost everything happens here. |
beta-llc | The neighbour, so isolation has something to be isolated from. |
gamma-coop | A third tenant, so lists have more than two rows. |
svc-demo | Machine identities only, no humans. Chapter 7. |
The four hats
The demo signs in four times, and knowing which hat is on is most of the story. Every slide says which one, in the corner and along the top edge:
| Hat | Who | Holds |
|---|---|---|
🛡️ admin | admin@example.com | Domain admin in Acme Corp. Most of the demo. |
🏗️ operator | operator@example.com | The platform grant. Creates Clouds, approves assignments. |
👤 member | member@example.com | An ordinary member. Proves what you get without a grant. |
🏢 beta | the same human, in Beta LLC | A different principal entirely. |
The operator row is the interesting one: it is not a bigger admin. It holds a grant that no Domain admin holds, and the Domain admin holds grants it does not.
Three more identities never sign in at all, and the badge names them too: 🖥️ shell before chapter 2, 🤖 machine in chapter 7, and 🔌 node in chapter 13.
The shape of the next hour
Tenancy — read a tenant, write into it, delegate access through groups, classify with labels, hand an identity to a machine.
Provisioning — build a catalog, bind a credential under two-party approval, provision a bucket, then reach a node without ever holding a key.
Mesh — speak the node contract by hand, then hand it to the agent written to speak it.
The last chapter is the one to stay for.