Halton Meter Cloud

Cloud security & compliance

Authentication, encryption in transit and at rest, region and residency, access controls, audit logging, and deletion guarantees for Halton Meter Cloud.

macOS 12+ · Python 3.11+ Reading time 2 min Updated May 11, 2026

The same posture as the daemon, in someone else’s datacenter — and the receipts to prove it.

The hosted Cloud at app.haltonmeter.com runs on AWS in eu-west-2 (London). The daemon’s local-only posture (see Local-only guarantee) is the baseline; Cloud sync is the explicit, per-field opt-in that extends that baseline to a hosted surface.

This page documents what the cloud does with your data, how it authenticates members and devices, and what you can demand back when you leave.

Authentication

Member auth (Clerk)

Member sign-in is handled by Clerk. The cloud backend validates Clerk-issued JWTs on every request, with strict azp (authorized party) validation pinned to https://app.haltonmeter.com — JWTs minted for any other origin are rejected.

Production sign-in supports:

  • Email + password
  • Email magic link
  • Google, GitHub OAuth
  • Passkeys (WebAuthn)
  • Time-based one-time password (TOTP) for two-factor

The cloud does not see or store your password — Clerk owns the credential surface. The backend only ever sees a verified user_id and the workspaces that user belongs to.

Device auth (hm_sync_… tokens)

A paired daemon authenticates with a hm_sync_… bearer token, minted by the pairing flow (see Connect your meter) and scoped to:

  • One workspace — the token can only post to /v1/[workspace_id]/....
  • One machine — the token carries the machine_id it was minted for. Replay from a different machine is detectable in the audit log.

Tokens have no expiry; they remain valid until you revoke them (from the dashboard, via halton-meter cloud disconnect, or via the workspace’s device list). Revocation is immediate — the next request returns 401 and the daemon transitions to paused_unauthorised.

API keys

For programmatic access, generate a workspace-scoped API key from /[workspace]/settings/advanced. API keys are:

  • Issued once, shown once (you must copy them on creation)
  • Hashed at rest with bcrypt; the cloud cannot recover a lost key
  • Scoped to one workspace; cannot read or write outside it
  • Revocable; revoked keys return 401 on the next request
  • Audit-logged on every use

Encryption

In transit

  • Member traffic — TLS 1.3 only between browser and app.haltonmeter.com; HSTS preload eligible.
  • Daemon → backend — TLS 1.3 only between daemon and api.haltonmeter.com. The daemon pins to the production cert via the system’s CA bundle, with no certificate-relaxation flags.
  • Backend internal — RDS Postgres is in private subnets; the only ingress is on port 5432 from the ECS task security group. No public endpoint, no public IP.

At rest

  • Postgres (RDS) — encrypted at rest with AWS KMS. Storage, automated backups (7-day retention), and point-in-time recovery snapshots are all encrypted.
  • SSM Parameter Store — every secret (Clerk keys, webhook signing secrets, Fernet envelope keys, DB URL) is stored as a SecureString with KMS encryption. The application reads them from SSM at boot; they are never present in plaintext on disk.
  • Daemon-side cloud credentials — ~/.halton-meter/cloud-credentials.json is mode 0600 (owner-readable only). A Fernet-encrypted mirror lives in the local SQLite store, with the symmetric key at ~/.halton-meter/cloud.key.

Body sync envelope

When you opt body sync in (see Sync and retention), the upload uses the standard TLS channel. The cloud stores bodies in the same encrypted Postgres column as metadata, keyed on request_id. The redaction_applied flag is OR-merged across the request and response directions.

Region & residency

  • Hosting region — AWS eu-west-2 (London), single-region. No cross-region replication.
  • Backup region — Automated snapshots stay in eu-west-2.
  • CDN — Static dashboard assets (Next.js build artefacts) are served from Vercel’s edge network; HTML responses originate from eu-west-2 Lambda. Marketing landing assets come from Cloudflare Pages.

If your compliance regime requires data residency in a different region (e.g. US data, German data residency), today the answer is Enterprise on-premises — same product, your AWS / Azure / GCP account, your jurisdiction. See app.haltonmeter.com/enterprise.

Access controls

Workspace-level RBAC

See Workspaces — Members and roles. Three roles: Owner, Admin, Member. Roles are checked on every authenticated request via the permissions module in the backend; a Member cannot escalate by guessing a URL — the API returns 403 for any action above their role.

Workspace isolation

Every cloud API request is scoped to one workspace. The backend’s scope dependency on every router asserts that the requesting member or device token belongs to the targeted workspace before any data is returned. There is no path that joins data across workspaces.

This matters when one Halton Labs employee is a Member of multiple client workspaces — their dashboard for workspace A cannot see workspace B’s spend, and vice versa.

Internal access

The Halton Labs team can access workspace data only through:

  • The audit-logged support path (a workspace Owner explicitly grants read access for a fixed window, e.g. 24h, for a specific Halton Labs support email).
  • Read replicas used for performance analytics — only aggregated, workspace-anonymised metrics flow through them.

No engineer at Halton Labs has standing access to any workspace’s raw data. Database admin access is gated by AWS IAM with MFA enforcement.

Audit logging

Every state-change on the cloud side writes an audit row:

  • Membership changes (invite, accept, revoke, role change)
  • Device pairings and revocations
  • Project rename, archive, restore
  • Configuration changes (policy edits, pricing-rate overrides)
  • Billing events (plan change, payment update, seat change)
  • API key creation and revocation
  • Workspace deletion

Workspace Owners and Admins can view the workspace’s audit log at /[workspace]/audit. CSV-exportable. Streaming export to a SIEM is on the Business+ and Enterprise plans.

The audit table is append-only at the application layer; the backend has no API to delete audit rows. Postgres-level deletion would require direct DB access and is itself logged in CloudWatch.

Compliance posture

Halton Meter Cloud is built for a SOC 2 Type II audit but is not yet certified. The architectural decisions documented above (encryption-at-rest, audit logging, role-based access, MFA-gated admin access, network isolation) are the controls SOC 2 auditors typically examine. Certification is on the path; until then we are honest about the state: SOC 2 ready, not yet certified.

GDPR posture:

  • We are a data processor for any workspace’s captured data; the workspace Owner is the controller.
  • We respond to data-subject access and deletion requests via operator@haltonlabs.com within 30 days. Practically, deletion is near-immediate because the workspace’s data is keyed by workspace_id and isolatable per request.
  • Our DPA (Data Processing Agreement) is available on request for customers who require one for procurement.

HIPAA, PCI-DSS, FedRAMP: these are not applicable to the hosted SaaS — LLM API cost metadata is not in scope for any of those regimes. For customers in those regulated environments, the answer is Enterprise on-premises.

Deletion & export

Member-initiated

  • Disconnect a device — local credentials wiped; cloud-side data retained per the workspace’s retention window. See Connect your meter — Disconnecting.
  • Delete a workspace — schedules deletion 30 days out; the workspace is read-only during the grace period; on day 30 every row keyed on the workspace_id is hard-deleted, including audit log.

Pre-deletion export

Before the 30-day window expires:

  1. Download every project’s PDF report from the projects list.
  2. CSV-export the audit log from /[workspace]/audit.
  3. JSON-export the full row set via the API: GET /v1/[workspace]/requests?from=2026-01-01&to=2026-12-31 with your API key.

Post-deletion residency

After the 30-day grace:

  • The workspace’s primary Postgres rows are removed.
  • The next automated backup (within 24h) carries forward without those rows; the previous backups still contain them and are retained per the 7-day backup window.
  • After 37 days from the deletion request (30-day grace + 7-day backup retention), no copy of the workspace’s data exists in our systems.

A point-in-time-recovery to a moment before deletion would require an explicit, audit-logged engineering action — not available through the dashboard.

Vulnerability disclosure

Report security issues to operator@haltonlabs.com with subject SECURITY:. We acknowledge within 24h, fix critical issues within 7 days, and publish a post-mortem after a fix ships. See Disclosure for the full process, PGP key, and our public commitment to responsible disclosure.

See also