Skip to main content

Security

This page describes how AppHaven protects your secrets, your code, and your running app, and where the line sits between what the platform secures and what remains your application's job.

Secrets​

Values you store as Secrets in the console are:

  • Encrypted at rest with AES-256-GCM, under a key that lives with the platform, not in the database alongside the data.
  • Write-only. Once saved, a secret's value is never shown again: not in the console, not in any API response, not to any role. You can replace it or delete it, but nobody can read it back. Keep the canonical copy of a secret in your own password manager.
  • Delivered directly to your services as environment variables at deploy time. The only place a secret's value reappears is inside your own app's environment.

One honest caveat: your app's logs show whatever your app prints. If your code logs a secret, that log is visible to your project's members; treat log output as part of your app's security surface.

caution

Build and runtime logs contain whatever your application writes to them. Don't print secrets.

Repository credentials​

Credentials for reaching your code are held to the same standard:

  • GitHub App connections are the recommended path: access is scoped to exactly the repositories you select, it is read-only (contents and metadata), and AppHaven works with short-lived installation tokens, minted per use and valid for about an hour, rather than a standing key.
  • Access tokens for other Git hosts are encrypted at rest with the same AES-256-GCM scheme as secrets. Use a token scoped to read access on the one repository.

Database credentials​

A managed database's name, user, and password are generated by the platform where the database runs, and stay there. They are never written to your repository, never stored in the console, and never displayed to anyone. Your app receives them at start through connection references. There is no credential for a person to mishandle, because no person ever holds one.

Workload isolation​

Every deployment runs in its own virtual machine with its own operating system. Isolation between your app and anyone else's (and between your production and your previews) is enforced by hardware virtualization, not by container boundaries within a shared kernel. The isolation is imposed by the platform from outside the machine, so it holds even if the application inside is fully compromised: such an app can serve its own ports and make outbound requests, and nothing else.

Builds get the same treatment: each build from source runs in a fresh environment that exists only for that build.

Network and transport​

Your app is reachable only on the ports declared in the manifest, only through AppHaven's edge, and only over HTTPS; certificates are issued and renewed by the platform. Internal service-to-service traffic stays on the deployment's private network and is never exposed.

Where your data lives​

You choose an EU region when you create an app, and the choice is fixed for the app's life. AppHaven is a European company on European infrastructure; see How AppHaven runs your app.

What stays your responsibility​

AppHaven secures the platform your app runs on and isolates apps from each other. What happens inside your application (which of its users may see which data, what its endpoints permit, how it validates input) is your application's logic, and no platform can take that over. The shared-responsibility table draws the full line.

Where to go next​