Forgeon Docs

Documentation, guides, and patterns to help you build on Forgeon — from your first deploy to running serious infrastructure.

Secure compute

Isolation, least privilege, and runtime hardening in Forgeon.

Last updated: 2026-03-17

Forgeon applies secure defaults to runtime environments.

Defaults

  • Non‑root runtime
  • Read‑only filesystem (where supported)
  • Minimal capabilities

What you control

  • Environment variables
  • Runtime scaling
  • Network exposure (domains)

Security model at a glance

  1. Build boundary: source is built in an isolated process.
  2. Runtime boundary: app runs with least privilege and restricted capabilities.
  3. Edge boundary: public traffic reaches runtime through managed routing.
  4. Policy boundary: plan limits and quota checks prevent abusive resource usage.

Operational hardening checklist

  • Store secrets only in environment variables (never commit to repo).
  • Separate staging and production credentials.
  • Restrict exposed domains to required environments only.
  • Enable monitoring alerts for unusual error-rate spikes.
  • Rotate credentials after incident response or team changes.

Recommendations

  • Keep secrets in env vars (never in repo)
  • Use staging to validate before production

Common security mistakes

| Mistake | Risk | Fix | | --- | --- | --- | | Secret committed in source | Credential leak | Revoke/rotate key and move to env vars | | Reusing prod DB in staging | Data exposure | Isolate data plane per environment | | Wide-open custom domain mapping | Unintended traffic exposure | Limit domain to intended project/env | | No traffic anomaly alert | Late incident detection | Add baseline alerts for 4xx/5xx spikes |

See also