← getamphora.com All papers Download PDF
amphora
Security & self-hosting
Written for the team that owns your servers

The questions your IT team will ask, answered.

Amphora is a single self-hosted application. This brief describes where data lives, how access is controlled, what is recorded, and what happens when something goes wrong.

Where the data lives

Who can do what

RoleScope
OwnerThe install's root account. Everything an admin can do, plus ownership-level settings. Exactly one; cannot be removed.
AdminFull operational and commercial access: customers, catalog, rate cards, users, settings.
WarehouseFloor work — receiving, putaway, moves, picking, packing, shipping. No pricing, billing or user management.
DeveloperAPI and documentation access for integration work.
VendorReserved for supplier replenishment. The role exists in the model; today it grants no access at all, and it is listed here so an account you see in the product is not a surprise in this document.

Roles are capability-based rather than page-based: the same check runs in the UI and in the API, so an endpoint cannot be more permissive than the screen that calls it.

Authentication

Transport security

Encryption and secrets

Stated precisely, because this is where vague answers waste everyone's time. Amphora does NOT encrypt its database file at the application layer today — encryption at rest is provided by the volume it sits on (LUKS, BitLocker, FileVault, or your cloud provider's encrypted disks), which is the same control most self-hosted databases rely on. The file is protected by OS permissions and lives wherever you put it. Application-level database encryption is on the roadmap, not in the product; if your policy requires it before the disk layer, say so during evaluation rather than after.

SecretHow it is stored
User passwordsscrypt (N=16384, r=8, p=1, 64-byte key) with a per-user random salt, compared in constant time. The hash format is self-describing, so parameters can be raised later without invalidating existing passwords.
Session tokensA 32-byte random token is issued to the browser; only its SHA-256 hash is stored. A stolen database yields no usable sessions.
API keysGenerated once, shown once, stored as a hash. A lost key is revoked and reissued, never recovered.
Two-factor backup codesHashed, single-use, and burned on redemption.
TOTP secretsStored in the database so the server can verify codes — one of the concrete reasons the disk should be encrypted.
Carrier / provider API keysWrite-only in the interface and never returned to the browser. An environment variable overrides the stored value, so a deployment can hold credentials outside the database entirely.

Patching and vulnerability response

What is recorded

Two independent records, both append-only. The INVENTORY LEDGER holds every physical movement — receipt, move, adjustment, status change, pick, shipment — with actor, reason code, quantities and timestamps; stock on hand is derived from it rather than stored, so a count can always be explained. The AUDIT TRAIL holds every consequential system action — sign-ins, permission changes, rate-card edits, key creation, shipment events — filterable by module and exportable as CSV. Corrections are new events; nothing is edited away.

Backup and recovery

What self-hosting asks of you

Somebody has to own the server: patches, backups, and a plan for the day the disk fails. In exchange, client data never leaves your building, the warehouse keeps working when the internet does not, and no third party can change your pricing, your terms, or your access to your own records.

Next step

Forward this to whoever owns your security review and send us their questionnaire — SIG, CAIQ, or your own. We answer it directly rather than pointing at a trust page, and we will tell you where the answer is "not yet".

parth@brandboxai.app