Local / Self-Hosted Deployment

The real, current deployment model: a single Node.js process, local PEM keys, your choice of memory or Supabase storage.

[AVAILABLE], this is what actually runs. Cloud/KMS/multi-instance/HA deployment is [ROADMAP], see Roadmap.

What runs today

One Express process (packages/api/src/server.ts), single instance, no load balancer or orchestration assumed. Signing keys are local PEM files read by FileKeyProvider. Storage is either fully in-process (memory, non-persistent) or Supabase.

Configuration

Real .env keys (from this repo, values redacted):

NODE_ENV=...
PORT=3000
PARMANA_STORAGE=supabase     # or: memory
HASH_PROVIDER=sha256
PRIMARY_SIGNATURE_PROVIDER=ed25519   # or: dilithium3 (needs Node >= 24)
KEY_PROVIDER=local
PARMANA_KEY_DIR=./keys
PARMANA_GATEWAY_KEY_ID=gateway       # optional, defaults to "gateway"
TRUST_PROFILE=v1
LOG_LEVEL=...                # read into config; no logger currently consumes it, see Roadmap
PARMANA_POLICY_DIR=...
HUBSPOT_PRIVATE_APP_TOKEN=...  # credential for the hubspot connector, omit to leave it unregistered
PARMANA_API_KEYS=...         # required, fails closed if unset, see Authentication

PARMANA_KEY_DIR is a single directory containing every keypair FileKeyProvider reads: default.*.pem (authorization signing/verification) and gateway.*.pem (gateway attestation, see Gateway attestation). They are deliberately separate keys in the same directory, not one key used for two purposes. PARMANA_GATEWAY_KEY_ID lets you point the gateway at a differently-named key pair (for example during rotation, run both gateway and gateway-v2 side by side, then flip the env var) without touching default.*.pem at all.

Running it

NODE_ENV=test \
  PARMANA_STORAGE=memory \
  PARMANA_POLICY_DIR=/absolute/path/to/policies \
  PARMANA_API_KEYS='[{"callerId":"demo","keyHash":"325ededd6c3b9988f623c7f964abb9b016b76b0f8b3474df0f7d7c23b941381f"}]' \
  npm run dev

NODE_ENV=test matters even though PARMANA_STORAGE=memory is set: two other components, the Execution Gateway’s replay-nonce store and the caller-authentication audit trail, default to Supabase-backed implementations outside NODE_ENV=test (createNonceStore.ts, createCallerAuditSink.ts) and will fail closed without a real, reachable Supabase project. PARMANA_API_KEYS above is the demo key already committed in this repo’s root .env, raw key my-secret-api-key, see Authentication.

Generate the gateway keypair first if you haven’t, npm run generate:gateway-keys, see Quickstart step 2. Without it, the server refuses to start: the gateway is wired unconditionally (see The gateway), there is no code path that skips needing this key.

What this deployment does not give you

• No self-service key management. Caller authentication is real and fails closed (see Authentication), but issuing and rotating keys is an operator action (scripts/generate-api-key.ts), not an API call.
• No KMS/HSM. Your private keys, both default.private.pem and gateway.private.pem, are files on disk, exactly the exposure that produced the incident noted on Security.
• Single process, single instance. No HA, no load balancer assumed. Whether replicas share replay-nonce state depends on NODE_ENV: MemoryNonceStore (NODE_ENV=test, as above) is process-local, each process would accept the same authorization once, not once fleet-wide (CLAIMS.md 3.2). Outside NODE_ENV=test, SupabaseNonceStore is durable and shared across replicas pointed at the same Supabase project, but this deployment shape is still one process behind no load balancer.
• Zero connectors registered by default. hubspot registers only when its credentials are configured (HUBSPOT_PRIVATE_APP_TOKEN). See The gateway for what adding another requires today.

Node version

Root package.json requires Node ≥ 22. ML-DSA-65 (post-quantum signing) specifically requires Node ≥ 24 for native node:crypto support (CLAIMS.md 2.14).