sodimo

Chapter 38 / 40

Account vault basics

Every digital account Sodimo relies on — the Cloudflare login, the domain registrar, the shared utility accounts, the SSH keys that reach the Framework Desktop, the API tokens the agents use — needs a single, shared, reliable place to live. That place is the Sodimo account vault.

This chapter is the employee-facing overview: what the vault is, how you get at it, and when you will and will not use it. The full technical specification — how the vault is implemented, backed up, and recovered, along with the authoritative list of who has access to what — lives in the companion chapter The vault (chapter 37, under Part 30 The infrastructure). Cross-reference that chapter for anything about implementation, backup, disaster recovery, or the on-disk structure.

Status: Planned — the vault activates on the Framework Desktop alongside the rest of the harness. Before it is live, credentials are self-managed per the How the system is built chapter (personal password manager + paper). The transition to the vault happens in one sitting with Thomas during the engagement.

What the vault is, in one paragraph

The vault is a Sodimo-hosted Vaultwarden instance running on the Framework Desktop — a Bitwarden-compatible server, so every Bitwarden client (the web app, the browser extensions for Chrome / Firefox / Safari, the iOS and Android apps) works against it unchanged. Each employee has their own Vaultwarden account, protected by a master password and a TOTP second factor. The vault is reached at vault.sodimo.eu through Cloudflare Access — so the outer gate is the same Google Workspace login you use for every other Sodimo tool.

In plain terms: it is the shared password manager the team already wishes it had, kept on hardware Sodimo physically owns, and it looks and feels like Bitwarden because it is Bitwarden under the hood.

What goes in the vault

Four collections, one rule: if Sodimo has a credential for it, it lives here. If it does not, the vault is wrong and the missing entry gets added.

  • SaaS passwords — Cloudflare, the domain registrar, the ISP portal, carrier accounts, the payment processor, the accounting software, GitHub, anything else with a login screen.
  • SSH private keys — the keys that reach the Framework Desktop, any dev box, the deploy keys used by CI. (Yes, private keys — the whole point of the vault is that it is the one place they can live.)
  • Service-account JSONs — Google Workspace service account, WhatsApp Business API credentials, the sendmail submission creds.
  • API keys for third-party integrations — the Anthropic API key, the Cloudflare API token, D1 tokens, any third-party SaaS token.

Each entry carries its own metadata — what it is for, who uses it, when it was last rotated — kept as custom fields alongside the secret.

What does not go in the vault

A few things live elsewhere on purpose:

  • Your personal Google Workspace password. That is your account, not Sodimo’s. You manage it in your own personal password manager (or, better, with a passkey).
  • The paper recovery set — domain registrar break-glass, Cloudflare root, LUKS recovery keys, the Vaultwarden admin token itself. These are written on paper and held by Jack and Paul, exactly because the vault needs to be recoverable even if the vault is lost. The paper set is the last-resort key; the vault is the day-to-day key.
  • Anything that is already single-sign-on through Google. The launchpad, the CRM, OpenWebUI, Piler — none of these need a separate password stored in the vault. If you can log into Gmail, you are in.

How an employee reaches the vault

Day-to-day, most employees never touch the vault for the services they already Google-SSO into. You reach it explicitly when:

  1. You need the password for a SaaS that is not behind Google SSO (the registrar, a carrier portal, a payment dashboard).
  2. You are setting up a new laptop and need to pull your vault onto it.
  3. You are standing in for Thomas on a maintenance task and need a specific API token or SSH key.
  4. You are rotating a key (see chapter Key rotation).
  5. You are onboarding a new teammate and need to grant them access to a collection.

The flow in each case is the same, and it is entirely browser-based — no VPN client to install, no Tailscale, no terminal. Just:

  1. Open vault.sodimo.eu in your browser.
  2. Cloudflare Access catches the request and asks you to pick your @sodimo.eu Google Workspace account. Approve.
  3. The Vaultwarden login page loads. Enter your Vaultwarden master password and your TOTP code.
  4. You are in. The web UI shows your collections — SaaS passwords, SSH keys, service-account JSONs, API keys — filtered to what your role allows.

That is it. Two logins (Google + Vaultwarden) plus one TOTP, all in the browser. The Tailscale overlay network is not part of this path — Tailscale is a maintenance tool Thomas uses for SSH work, not something Sodimo employees install or configure.

For day-to-day use, install the browser extension and the mobile app. Sign in with the same account. Autofill then works on every saved site; the mobile app covers you when you are away from your laptop. One-time setup, perpetual payoff.

Who can read what

Vaultwarden organises entries into collections, and each collection has a set of people and services who can read or write it. The authoritative mapping lives in chapter The vault; the roles in human terms are:

  • Master operator — Thomas during the engagement, Michel after handoff. Has the Vaultwarden admin token, can reset any account, can edit access lists.
  • Writers — Thomas and Paul. Can add, edit, and share entries across all collections.
  • Readers — Rani, Jack, and any other Sodimo employee. Scoped per-collection — Rani reads the CRM and mail credentials, Jack reads the legal and administrative ones, neither reads the infrastructure ones.
  • Service principals — no human login. Narrow per-service access so the sodimo-etl service can read its D1 token and nothing else. These accounts never log in through a browser; they authenticate with a machine credential.

Granting a new Sodimo hire reader access is a two-minute operation in the Vaultwarden admin UI. The Key rotation chapter covers the offboarding mechanics.

Where to go next

  • Rotating a key, or wondering when the next rotation is due → chapter Key rotation.
  • Setting up a new SSH key from scratch → chapter SSH basics.
  • The technical specification, backup strategy, recovery procedure, and full access matrix → chapter The vault (chapter 37, Part 30).

The vault is boring on purpose. Every time the team thinks “where is that password?”, the answer is one sentence: “open vault.sodimo.eu”.