Forge64 security

The strongest isolation boundary in Forge64 is the database. An app does not share tables with other apps. Row-level security is the second layer inside each database.

• BuiltEach app gets its own Postgres database and two login roles (the app role and an identity role), created by the provisioning saga.
• BuiltTenant login roles have every privileged attribute switched off (superuser, create-database, create-role, replication, bypass-row-level-security). Verified by tests against a live Postgres 17.
• BuiltConnecting to another tenant's database is revoked at the PUBLIC level, so a tenant role cannot open a connection to a neighbour's database.
• BuiltA database cluster refuses to create more than 250 tenant databases (it fails closed). Beyond that a new cluster or shard is required; sharding itself is not built.
• BuiltPlatform-owned tables are registered in a row-level-security audit, and the generation audit flags generated apps whose user-data tables lack ENABLE ROW LEVEL SECURITY.
• Rolling outPer-tenant connection pooling with per-plan connection limits.

Apps run as containers on Forge64-operated servers. The design blocks a tenant container from reaching other tenants' containers, the scheduler and host admin ports, and cloud metadata addresses, and caps how much network a single app can use.

• Rolling outFirewall rules for the container bridge, the scheduler admin ports and the host input chain are written and proven in kernel network namespaces (33 checks pass). They are not yet applied on the production server.
• Rolling outPer-app network caps: a limit of 256 open connections, 50 new connections per second and 2 MiB per second per app, with a 6 MiB per second aggregate cap per node. The throughput effect of these caps has not been measured.
• Rolling outThe container networking plugin is version-pinned and checksum-verified before install.
• Rolling outMoving all database traffic onto a private path so the database port is not reachable from the internet. Until that completes, database access relies on per-app credentials rather than network position.

• BuiltApp environment secrets are encrypted with AES-256-GCM before they are stored. Data keys are derived per tenant and purpose from a platform key held as a write-only platform secret.
• BuiltExports and logs carry secret names only, never secret values.
• RoadmapData keys are derived from a platform key; they are not held in a separate hardware-backed key service. An external KMS or HSM is not built.
• Rolling outDatabase backups are encrypted with AES-256 before they leave the server.
• BuiltTraffic to apps and the API is encrypted in transit with TLS. App certificates are issued automatically for hostnames the Forge64 API approves.
• RoadmapFull-disk encryption of the application servers is not claimed on this page.

• BuiltBilling and project mutations are written to an audit log in which each entry stores the SHA-256 hash of its content plus the previous entry's hash. Verification recomputes the chain and detects an edited or removed entry.
• BuiltOrganization audit-log endpoints and single sign-on (OIDC and SAML) for Enterprise organizations.
• RoadmapSCIM provisioning, IP allowlisting and customer-selectable data residency.

Backups are where the gap between design and production is largest, so this section states the production reality first: at the review date production keeps a nightly local database dump on the same server. That protects against a bad deploy or a dropped table, not against losing the server. The off-server system below is built and is being applied.

• Rolling outEncrypted backups shipped off the server to storage in a different location, with a weekly full backup, daily differential backups, and a retention of four full and seven differential backups.
• Rolling outA restore drill measured a recovery time of 29 seconds on a small test database. That is a test result, not a promise for production-sized data.
• BuiltYou can export your own app (source, database rows, uploaded objects' metadata and a manifest) at any time without Forge64's involvement.
• RoadmapPoint-in-time recovery to an arbitrary second and automatic failover to a standby database.

• BuiltEvery billable resource has per-account, per-app, per-plan and platform-wide daily limits that refuse the operation when reached (fail closed), rather than queueing or degrading silently.
• Rolling outCircuit breakers on platform usage (requests, key-value, queue and database operations) refuse traffic before a vendor bill can grow, and a kill switch can stop it.
• BuiltSign-up has an invitation mode, bot checks and per-address caps.
• Rolling outWeb application firewall and rate-limit rules for the public API, defined as infrastructure-as-code.

• BuiltA public status page at /status that shows 'unknown' instead of 'operational' when monitoring cannot be reached.
• Rolling outAn owner-only security agent (Guardian) with a hash-chained event stream, detectors and approval-gated actions. It is built but its wiring to live services has not been verified.
• Rolling outError tracking with personal data and secrets scrubbed, kept in Forge64's own systems rather than sent to a third-party service, plus a per-minute synthetic monitor.

• BuiltContinuous integration blocks merges on a required-checks list that includes secret scanning and workflow linting. Applied database migrations cannot be edited, and destructive migrations need an explicit expand-then-contract marker.
• Rolling outGradual production rollout (10%, 50%, 100% with automatic return on failed probes) and a one-command rollback.
• BuiltMutating browser requests are protected by CSRF middleware, and sign-in uses a maintained authentication library.

Forge64 keeps written incident runbooks with three severity levels. The response-time figures in them are internal targets, not guarantees, and Forge64 does not offer an uptime SLA on self-serve plans.

• BuiltWritten runbooks for severity levels P1 (critical, 30-minute recovery target), P2 (major, 2-hour target) and P3 (minor, 8-hour target), with declare, assess, mitigate and review steps.
• RoadmapA contractual SLA for Enterprise customers.

Send reports to security@forge64.dev with steps to reproduce. The disclosure policy is published as a security.txt file at /.well-known/security.txt (RFC 9116). Please do not access other users' data, run denial-of-service tests or test against other customers' apps. Forge64 does not run a paid bug bounty.

How does Forge64 keep one customer's app from reading another's data?

Each app has its own Postgres database and its own login roles with privileged attributes switched off, and connecting to other tenants' databases is revoked. Row-level security inside each database is the second layer. Network firewalling between tenant containers is implemented and is being applied to production.

How does Forge64 store my app's secrets?

Secrets are encrypted with AES-256-GCM before storage, using data keys derived per tenant from a platform key held as a write-only platform secret. Exports and logs contain secret names, never values. The keys are not held in a hardware security module.

Does Forge64 back up my database off-server?

The off-server system is built (encrypted backups shipped to storage in another location) but is still being applied. At the review date production keeps a nightly dump on the same server, so you should also keep your own exports.

Is Forge64 SOC 2 certified?

No. Forge64 holds no third-party security certification at the review date.

How do I report a vulnerability to Forge64?

Email security@forge64.dev and see /.well-known/security.txt. Forge64 does not run a paid bug bounty.

What happens if there is a security incident?

Forge64 follows written incident runbooks with three severity levels and updates the public status page. The recovery times in the runbooks are targets, not guarantees, and there is no uptime SLA on self-serve plans.