Security
Your servers stay yours. Here's how.
How the agent connects, what we store, how it's encrypted and who can get to it.
An overview, not the fine print. This page describes how Fwoop is designed. Our full security documentation, report summaries and certifications will be published here as they're completed. Need more for a review today? Email security@fwoop.dev.
Architecture
Agent and network
The agent runs as its own fwoop system user and connects out to the control plane over TLS 1.3 on port 443. It never opens a listening socket, so your servers can keep a default-deny inbound firewall, with no VPN or bastion host needed.
The agent only acts on instructions that come from your workspace, each tied to a person or token and recorded in the audit log. Agent releases are signed, roll out in waves and roll back automatically if they fail their health check.
What we store
Fwoop keeps what it needs to run your fleet, and nothing it doesn't.
Stored by Fwoop
- Account and member details
- Server names, labels, OS and agent version
- Configuration: services, jobs, backup plans, alert rules
- Metrics and run history, for your plan's retention
- Secrets, encrypted with your workspace key
- The audit log
Never stored by Fwoop
- Your application data and databases
- Container logs (streamed live, never kept)
- Backup contents (encrypted, in your bucket)
- Plaintext secrets
- SSH keys or root passwords
Encryption
In transit: TLS 1.3 for agent connections, TLS 1.2 or newer everywhere else, with HSTS on every web property.
Secrets: AES-256-GCM with a data key per environment, wrapped by a key per workspace (envelope encryption). Agents decrypt values only for the containers that reference them, and keep them in memory.
Backups: encrypted on your server with a repository key you hold a copy of, before anything is uploaded to your bucket.
At rest: the control plane's databases and disks are encrypted, and so are its own backups.
Access and identity
Two-factor authentication on every plan, with the option to require it. SSO with SAML or OIDC on Business and Enterprise, SCIM provisioning on Enterprise, and roles per project that separate deploying from reading secret values.
Fwoop staff have no standing access to customer workspaces. Support access needs your explicit, time-limited approval, is read-only and appears in your audit log.
How we operate
Production access is limited to a small group of engineers, through SSO with hardware security keys, and every session is logged. Changes go through code review and automated tests before they ship. Dependencies are scanned continuously and patched on a schedule based on severity.
The control plane is backed up continuously, and restores are tested. If the control plane is unreachable, agents keep running your services and cron schedules and sync once it's back.
Reporting a vulnerability
If you think you've found a security issue in Fwoop, email security@fwoop.dev with the details and steps to reproduce. Please don't access data that isn't yours, and give us reasonable time to fix the issue before telling anyone else.
We won't take legal action against good-faith research that follows these rules, and we'll credit you if you'd like.
Compliance
Fwoop is in early access and doesn't hold certifications yet. Until it does, we're happy to complete security questionnaires, walk your team through the architecture and share our policies under NDA. Our data processing agreement and list of subprocessors are available on request, and Enterprise customers can run the control plane in their own environment.
Questions from your security team?
We'll walk them through the architecture, answer the questionnaire and share what they need under NDA.