Hardening a self-hosted payment gateway: a practical deployment guide.

When you self-host a payment gateway, security stops being a line in a vendor's trust page and becomes your own engineering. That is the point — you get to inspect and control it — and also the responsibility. The good news is that a hardened deployment is not exotic. It is a layered set of ordinary controls applied consistently.

This guide is written for the engineer who has just been handed a gateway to deploy. It is not a compliance framework, and it does not replace a review by your own security team. It is a practical baseline organised by layer, with the reasoning for each control so you can adapt it.

A mental model: reduce, contain, detect

Layer 1: the network

Layer 2: containers and hosts

A container is not a security boundary by itself, but sensible defaults shrink what a compromise can do. The OWASP Docker guidance ^[1] covers this in depth; these are the highest-value items.

FROM node:22-slim AS build
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile
COPY . .
RUN pnpm build

FROM node:22-slim
ENV NODE_ENV=production
WORKDIR /app
COPY --from=build /app/.next ./.next
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/package.json ./
USER node                       # never run as root
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s CMD node -e "fetch('http://localhost:3000/healthz').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"
CMD ["node", "node_modules/next/dist/bin/next", "start"]

services:
  gateway:
    image: registry.example.com/gateway:1.4.2      # pin a version, never :latest
    read_only: true                                # immutable root filesystem
    tmpfs: ["/tmp"]
    user: "node"
    cap_drop: ["ALL"]                              # no extra Linux capabilities
    security_opt: ["no-new-privileges:true"]
    environment:
      DATABASE_URL_FILE: /run/secrets/database_url # secrets from files, not env dumps
    secrets: [database_url]
    networks: [internal]
    deploy:
      resources:
        limits: { cpus: "1.0", memory: 512M }

• Pin image versions and verify digests. A moving tag means you deploy different code without deciding to.
• Scan images. Run a vulnerability scanner in the pipeline and fail on serious findings with a fixable version.
• Keep hosts minimal and patched. Fewer packages, automatic security updates, and an owner for the base image.
• Limit resources. A runaway process should hurt itself, not its neighbours.

Layer 3: secrets

Secrets are the crown jewels: database credentials, webhook secrets, RPC keys, and above all anything involved in signing. The OWASP secrets-management guidance ^[2] and the twelve-factor principle of configuration in the environment ^[7] agree on the essentials, refined by modern practice: prefer short-lived, narrowly scoped credentials pulled at runtime over long-lived values baked into images or files.

Layer 4: the database

Payment state lives in PostgreSQL. It deserves authentication, least privilege, encryption, and above all, backups you have actually restored.

-- the application role can read and write its own tables, nothing else
CREATE ROLE gateway_app LOGIN PASSWORD :'app_password';
GRANT CONNECT ON DATABASE gateway TO gateway_app;
GRANT USAGE ON SCHEMA public TO gateway_app;
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO gateway_app;
REVOKE DELETE, TRUNCATE ON payments, payment_events FROM gateway_app;  -- history is append-only

-- a separate role runs migrations; the app role cannot alter schema
CREATE ROLE gateway_migrator LOGIN PASSWORD :'migrator_password';
GRANT ALL ON SCHEMA public TO gateway_migrator;

Backups and restores

A backup you have never restored is a hope. Continuous archiving and point-in-time recovery ^[6] let you rebuild to a chosen moment, which matters when the problem is a bad change rather than a dead disk.

1. 01

   Take base backups on a schedule

   Plus continuous archiving of write-ahead logs.

2. 02

   Encrypt and store them elsewhere

   A different account or region, with separate credentials.

3. 03

   Restore into a scratch environment monthly

   Time it. Verify the data and run reconciliation against it.

4. 04

   Write the recovery procedure down

   Including who decides and how long recovery should take.

5. 05

   Alert on backup failures

   A silent backup failure is discovered at the worst time.

Layer 5: the application

• Validate all input. Treat every request field as untrusted; the API security top ten ^[4] is a good checklist for object-level authorisation, rate limiting, and mass assignment.
• Verify webhook signatures on the raw body. And enforce timestamp tolerance.
• Authenticate operators properly. Single sign-on, multi-factor authentication, and role-based access to dangerous actions.
• Log security-relevant events. Logins, permission changes, signature requests, and replays, to storage the application cannot alter.
• Handle errors safely. No stack traces or secrets in responses.

The signing path is special

Anything that can request a signature deserves extra controls: a narrow interface, policy checks, approval requirements, and alerts on unusual use. See the signing-boundary post for the design.

Layer 6: supply chain and change

Layer 7: monitoring and alerting

Hardening reduces the chance of an incident. Monitoring decides how long one lasts. Alert on things that should be rare, not on everything.

A hardening review you can run this week

Application security verification standards ^[3] give a more formal way to structure such a review as your programme matures. Start with the baseline above, own it with names and dates, and improve it deliberately. A boring, consistently applied deployment is far safer than an ambitious one nobody maintains.