Hapimatic Cloud — Consent & Data-Handling Statement

INFO

Hapimatic Cloud is in pilot. This page is for pilot users.

DRAFT — PENDING REVIEW BEFORE FIRST USE

This statement describes a real trust relationship and must be reviewed and approved by the operator (Matt Starfield) before it is shown to any user or used to gather acknowledgment. Every claim below is traced to a specific epic #999 decision (D999-x); accuracy is load-bearing, not boilerplate. Do not treat this as final wording.

This is a plain-language description of what Hapimatic Cloud does with your data and your machine, what the operator can and cannot access, and how you can leave. Please read it in full before your instance is provisioned. You will be asked to acknowledge it.

There is no legalese here on purpose. The single most important fact is stated plainly: the operator holds SSH access to a machine that runs your Claude Code sessions. You should accept that trust knowingly, or not proceed.

What Hapimatic Cloud is

When you onboard, the operator provisions a single-tenant cloud virtual machine (VM) that is yours alone. It runs on Oracle Cloud Infrastructure (OCI, us-ashburn-1). Your VM hosts a private Hapimatic server, reachable at your own subdomain https://<your-subdomain>.hapimatic.com, which wraps Claude Code so you can drive coding sessions from a browser or phone.

Your VM is not shared with other users. Each user gets their own VM.

What runs on your VM

Component	What it is
Hapimatic server	The web app you log into; manages your Claude Code sessions
Claude Code	Anthropic's coding agent, authenticated to your own Anthropic account
Your session data	Conversation transcripts, session state, and any files you create live on your VM's disk
A reverse proxy (Caddy)	Terminates TLS for your subdomain
A backup agent	Takes nightly encrypted backups (see below)

Your Anthropic credentials, your prompts, and your code all live on your VM.

What the operator can access

This is the core of the trust relationship. Be clear-eyed about it.

• The operator holds SSH access to your VM. The operator's key is installed on your VM so the control plane can set it up (initial provisioning), deliver software updates, and provide support — over public-IP SSH (port 22). In practical terms, the operator can log into your running VM and see files on it, including session transcripts. It is the trust you are being asked to extend.
• Health monitoring does NOT use this access. Your VM self-reports its liveness and disk/health over HTTPS (/api/health); the operator never SSHes in to monitor. Monitoring is read-only self-reporting, not remote access.
• The operator does NOT put repository or cloud credentials on your VM. Software updates are delivered from the operator's control plane; your VM never holds a GitHub token or cloud API key that could reach the operator's private code or other infrastructure (decision D999-10). Even though you have a full shell on your VM, there is nothing there to exfiltrate the operator's systems with.

Your network — your own Tailscale tailnet

Your VM joins your own Tailscale tailnet, using an auth key you create and provide at onboarding. It never joins the operator's personal network (decision D999-8).

Why this matters: you have a full shell on your VM, and your own devices are on the same tailnet. If your VM joined the operator's network, you would become a network peer of the operator's home machines and of every other user. Per-user tailnets make cross-user and user-to-operator reachability structurally impossible, with no ongoing access-list maintenance. The Tailscale auth key you provide is used once to join the network and then deleted from the VM; it is not stored. See the Tailscale setup guide for how to create the key — and note that Tailscale is optional (there is a "skip for now" path).

What is backed up, and how it is protected

Your VM takes nightly backups to encrypted cloud object storage. Two protections apply (decision D999-9):

1. Your Anthropic credentials are excluded. The file that holds your Claude Code OAuth token (~/.claude/.credentials.json) is never included in a backup. If a backup is ever restored, you simply re-authenticate — the operator never takes custody of your live Anthropic credentials in a backup.
2. Backups are age-encrypted by default. Each VM generates its own age encryption keypair on the VM at provisioning. The private decryption key (identity) is shown to you exactly once through your instance's own authenticated UI (Admin → Backup Key) — you save it, confirm, and the VM then deletes it. It is never retained on operator infrastructure and the operator never sees it. The operator stores only the encrypted backup objects and cannot read their contents. Encryption is the default, not an opt-in.

In short: your credentials are not in the backups at all, and the backups the operator holds are encrypted with a key the operator does not keep.

Keep your backup key

Because the operator does not retain your age decryption identity, you are responsible for keeping it safe. If you lose it, encrypted backups cannot be recovered.

Software updates — the trust model

Your VM's Hapimatic software is updated on an operator-controlled model (decision D999-10, issue #1006 R10):

• The operator's control plane downloads and verifies each new release, then pushes a staged copy to your VM. Your VM reads only a local marker file to learn an update is available — it makes no external code-fetch call and holds no repository credentials.
• Your VM shows an "update available" badge. A background timer checks for updates roughly every 6 hours in check-only mode — it never applies an update on its own.
• You trigger the update when you choose to. The swap is atomic and rolls back automatically if the new version fails to start.

This means: the operator controls what code is offered to your VM, and you control when it is applied. The toolkit's separate auto-update path is off by default.

Offboarding and data deletion

You can leave at any time. When you offboard, the operator runs a deprovision process that (decision D999-12):

• Deletes your VM and its disk,
• Removes your subdomain's DNS record,
• Removes your account mapping from the login gateway,
• Revokes the deploy keys used to reach your VM,
• Exports your encrypted backups to you, then deletes them from operator storage.

One step is yours to complete: because your VM lived on your tailnet, the operator cannot remove it from your network. You remove the <your-subdomain> node from your own Tailscale admin console (decision D999-8).

After offboarding, the only copies of your data are the encrypted backups the operator exported to you (which only you can decrypt) and anything you separately saved.

What you are acknowledging

By proceeding, you acknowledge that you understand and accept:

• [ ] The operator holds SSH access to a VM that runs your Claude Code sessions and can, in principle, access files on it including transcripts.
• [ ] Your VM runs Claude Code under your own Anthropic account and subscription.
• [ ] Your VM joins your own Tailscale tailnet (or you skip Tailscale), never the operator's.
• [ ] Backups exclude your Anthropic credentials and are age-encrypted with a key you hold; the operator cannot read backup contents and you are responsible for keeping your backup key.
• [ ] Software updates are operator-controlled (what) and user-triggered (when), and your VM holds no repository or cloud credentials.
• [ ] On offboarding, your data is deleted from operator infrastructure (backups exported to you first) and you remove your VM from your own tailnet.

---