Sign up
Legal

Security Statement

Draft pending legal review. Placeholders in [brackets] will be completed before this document takes effect.

Last updated 30 September 2026

This statement describes how [BEESWORX LEGAL NAME] (Reg. No. [BEESWORX REGISTRATION NO.]) ("Beesworx", "we") secures Forge, the managed application platform at forgeserver.app. It describes the controls the platform actually runs today, including their limits. It is a description, not a warranty: the commitments we make to you are in the Terms of Service and the Data Processing Agreement.

1. Encryption

  • Secrets at rest. Application secrets, database credentials and third-party API keys stored by Forge are encrypted with AES-256-GCM under a key held on the server, outside the database.
  • Backups. Database backups are encrypted with the same scheme before they are written to disk or copied off the host.
  • API keys and passwords. Forge API keys are stored only as SHA-256 hashes; the full key is shown once, when it is created. Account passwords are held as hashes by our self-hosted identity service (Ory Kratos).
  • In transit. Every public hostname on the platform (the dashboard, the API, your apps and your verified custom domains) is served over HTTPS with certificates issued and renewed automatically. Forge's own dashboard and API hostnames send HTTP Strict Transport Security (one year, including subdomains), along with headers that prevent framing, MIME sniffing and loading scripts from other origins. The managed PostgreSQL server accepts TLS connections, with a key generated for this platform; the PgBouncer connection pooler in front of it does not currently offer TLS [OWNER TO CONFIRM WHICH DATABASE PORTS ARE REACHABLE FROM OUTSIDE THE HOST ON FORGESERVER.APP]. Traffic between the web server and your containers stays on private networks inside the host and is not separately encrypted.
  • Disk encryption. [OWNER TO CONFIRM WHETHER THE HOSTING PROVIDER ENCRYPTS DISKS AT REST ON FORGESERVER.APP].

2. Tenant isolation

Forge is multi-tenant: many customers' apps run on shared servers. These controls keep tenants apart.

  • Separate databases. Each customer's PostgreSQL, MariaDB and Redis resources are separate databases with their own credentials, not rows in a shared table.
  • Organisation scoping. Every request to the Forge API is resolved to an organisation, and every query on the platform's own records is filtered by it in application code. PostgreSQL row-level security policies back this up on the read path. Another organisation's resources answer as "not found", so their existence is not disclosed.
  • Sandboxed containers. Every customer application container runs under gVisor, a sandbox that intercepts system calls so a compromised app does not talk to the host kernel directly. This has been enabled on forgeserver.app since 30 September 2026. [OWNER TO CONFIRM WHETHER CUSTOMER IMAGE BUILDS ALSO RUN IN THE SANDBOXED BUILDER ON FORGESERVER.APP].
  • Separate networks. Each app runs on its own container network, joined only by the platform's own services and the managed services the app is bound to. Apps in the same organisation also share an organisation network; apps in different organisations do not share one.
  • Resource limits. Customer containers run with CPU, memory and process limits set by the plan, so one tenant cannot starve the others.
  • Egress boundary. A firewall boundary, re-applied every 30 seconds, stops traffic leaving the host from any customer container from reaching cloud metadata endpoints or private network ranges. This closes a common server-side request forgery path. It does not cover addresses the host itself owns, so apps that fetch user-supplied URLs should still validate them. Where configured, outbound connections to port 25 and known mining-pool ports are also blocked [OWNER TO CONFIRM ENABLED ON FORGESERVER.APP].
  • Build isolation. Processes that read a customer's compose file or Dockerfile run with an environment built from scratch that carries none of the platform's own secrets, and Forge deploys from a validated snapshot of the compose file rather than the customer-writable copy.

3. Access control

  • Sign-in. Accounts sign in with a password or a passkey, with an optional authenticator-app (TOTP) second factor. E-mail verification and a captcha can be required at signup.
  • Rate limits. Login, signup, e-mail verification and passkey sign-in are limited to 10 requests per minute per IP address. Login, the second factor step, e-mail verification and passkey sign-in are also limited to 10 attempts per minute per account, so rotating IP addresses does not help an attacker guess a password or a code.
  • Roles and permissions. Each organisation member is an owner, admin, member or viewer, mapped to a read, deploy or admin permission level. API keys carry a permission level no higher than the person who created them. Database passwords and other credentials are hidden from anyone below deploy permission.
  • Platform administrators. Install-wide settings (cluster, DNS, the platform e-mail provider) are restricted to platform administrators. When a platform administrator works inside a customer organisation, they do so with that organisation's owner permissions, without platform authority. Platform administrators can technically query customer databases and run commands in customer containers; this access is restricted by policy to support, security incidents and legal obligations, and is not currently recorded in the audit log. [OWNER TO CONFIRM WHO HOLDS PLATFORM ADMINISTRATOR ACCESS AND WHETHER A SECOND FACTOR IS REQUIRED FOR THEM].
  • Audit log. Administrative and lifecycle actions (for example sign-ins, API key and secret changes, and resource creation and deletion) are recorded with the acting identity, target and time. Coverage is not yet universal.

4. Backups and recovery

Where scheduled backups are enabled [OWNER TO CONFIRM ENABLED ON FORGESERVER.APP], Forge takes an encrypted backup of every PostgreSQL database, every dedicated Redis instance and every managed MariaDB database once a day, one at a time, and keeps scheduled backups for [BACKUP RETENTION, default 7 days]. Each scheduled backup is also copied to off-host storage at [OFF-HOST BACKUP PROVIDER AND LOCATION], separate from the primary host. Failed backup runs alert the operator. You can take a manual backup at any time and restore a backup either in place or into a new database. Object storage buckets and shared (non-dedicated) Redis are not covered by these backups. [RECOVERY TIME AND RECOVERY POINT OBJECTIVES, IF ANY, OWNER TO CONFIRM].

5. Abuse monitoring

Where enabled, Forge watches for the signature of cryptocurrency mining (a container pinned at its CPU limit for over 30 minutes), stops the container and alerts the operator. Abuse reports are handled under the Acceptable Use Policy, and e-mail sent through the platform is subject to the Anti-Spam Policy.

6. Incidents and breach notification

If we become aware of a security compromise affecting personal information we process for you, we will notify your organisation's owners and admins as set out in the Data Processing Agreement.

7. Reporting a vulnerability

Please report security vulnerabilities privately to [SECURITY CONTACT, e.g. security@forgeserver.app]. The platform also publishes a machine-readable contact at /.well-known/security.txt [OWNER TO CONFIRM IT POINTS AT A CONTACT OUTSIDE REPORTERS CAN REACH]. Please include what an attacker gains, the smallest set of steps that reproduces it, and the time you observed it.

We acknowledge security reports within 2 business days. For critical vulnerabilities affecting tenant isolation or host compromise, we aim to have a fix or mitigation plan within 30 days. We do not run a bug bounty, but we credit valid reports unless you ask us not to. Please do not access other customers' data, degrade the service, or run automated scanning against the platform while testing.

8. Your responsibilities

Security is shared. You are responsible for the code you deploy and its dependencies, for protecting the credentials and API keys we issue to you, for choosing strong passwords and enabling a second factor, for the permissions you grant your team members and their API keys, and for validating any URLs your apps fetch on behalf of their users.

9. Certifications and service levels

[CERTIFICATIONS, IF ANY, e.g. ISO 27001 OR SOC 2; OWNER TO CONFIRM. Forge does not hold any certification the codebase can evidence.] [UPTIME OR RESPONSE-TIME SLA, IF ANY, OWNER TO CONFIRM].