Trust

Security

qhost runs code from many customers on shared servers, so security is built into every layer: how workloads are isolated, what they can reach, how secrets are stored and how accounts are protected. This page describes what we do today.

Last updated October 25, 2026

Workload isolation

• Every service runs in its own container with CPU, memory and process limits set by its plan, so one workload can't starve the others. Containers don't swap.
• Containers run without privilege escalation (no-new-privileges), with raw sockets, device creation and other unneeded Linux capabilities removed, under seccomp and AppArmor profiles.
• Each project environment has its own private network. Services of other customers are unreachable, and private names (*.qhost.internal) resolve only inside the environment.
• Names and addresses of the platform's own components are reserved, so a workload can't impersonate them.

Network controls

• All traffic to your apps and the dashboard is served over HTTPS with automatically renewed certificates, behind Cloudflare's network.
• An egress firewall on every server keeps workloads and builds away from the server itself, the platform's internal services, the cloud provider's metadata and private networks.
• Outbound SMTP on port 25 is closed to prevent spam; send email through a provider on ports 465 or 587.
• Servers accept connections only on the ports the platform needs; SSH requires keys and repeated failed logins are banned. Traffic between servers travels over an encrypted WireGuard network.

Data and encryption

• Environment variables, GitHub tokens, two-factor secrets, webhook secrets and server credentials are encrypted at rest with AES-256-GCM.
• Passwords are never stored, only bcrypt hashes. Payment card data is handled entirely by Stripe and never touches our servers.
• Managed databases can be reached publicly over TLS, and backups can be scheduled from the dashboard.
• Webhooks and imports from external services can't be pointed at internal addresses.

Account security

• Two-factor authentication with an authenticator app, and passkeys.
• Session cookies are HttpOnly, Secure and bound to the dashboard's host; state-changing requests must come from the dashboard itself, which blocks cross-site request forgery.
• Sign-in, sign-up and two-factor attempts are rate limited against password guessing.
• Project tokens can be scoped to a single environment, and workspace roles limit what each member can change.
• Administrative access to the platform requires a passkey confirmation, expires quickly and every action is recorded in an audit log.

Builds

• Builds run with capped CPU, memory and processes and are stopped after 30 minutes.
• Repository paths (root directory, Dockerfile, config file) can't lead the build outside your repository, even through symbolic links.
• Build arguments and secrets are kept out of build logs.

Abuse prevention

Shared infrastructure stays healthy only if it isn't abused. qhost refuses deployments that contain cryptocurrency miners, blocks connections to mining pools and the stratum protocol, watches running services for miner processes and long CPU saturation, and automatically suspends workspaces caught mining. The rules are in the Acceptable Use Policy; report abuse to [email protected].

Infrastructure and operations

• Servers receive operating system security updates automatically.
• The platform database is backed up before every platform update.
• Access to production is limited to the qhost team and uses individual SSH keys.
• Availability is monitored continuously and published at status.qhost.dev.

Your part

Security is shared. We secure the platform; you secure what you deploy on it. Keep your dependencies updated, never commit secrets (use environment variables instead), turn on two-factor authentication, give workspace members only the role they need, and rotate tokens you no longer trust.

Report a vulnerability

Please give us reasonable time to fix the issue before disclosing it, only test against your own accounts and projects, and don't access other customers' data, degrade the service or run denial-of-service, spam or social engineering tests. We won't pursue legal action against research done in good faith within these rules.