Security

How we keep your sites safe

This page describes how Kernel6 protects your account, your secrets and the websites you run with us. It covers what is in place today. We would rather undersell than overclaim.

Last updated 3 October 2026

Your secrets

  • Environment variables are encrypted at rest with AES-256-GCM, each value with its own random nonce. They are decrypted only at deploy time, on the way to your server.
  • They are write-only from the dashboard. Once saved, a value is not shown back to anyone through the dashboard, including Kernel6’s own support staff, whose read access to projects deliberately excludes environment variables.
  • On your server, the values are written to a .env file readable only by the account that runs your app.
  • The SSH keys we use to reach servers and the cloud credentials we use to create them are encrypted the same way. None of them sit in our database as plain text.

Your account

  • Passwords are hashed with bcrypt and must be at least 10 characters. We never store or see the password itself.
  • Sessions use a signed token in an HttpOnly, SameSite=Lax cookie that scripts cannot read. It expires after 7 days. Changing or resetting your password signs out every other session immediately.
  • Password reset links carry a 256-bit random token, stored only as a hash. They expire after an hour, and requests are rate-limited so the form cannot be used to flood someone’s inbox. Links are always built from our own address, never from details in the request, so they cannot be redirected to another site.
  • Sensitive changes need your password. Changing your email address or deleting your account asks for it again. When your email address changes, we notify the old address, the one an attacker would no longer control. Security emails include the IP address the change came from.
  • Staff access is granted by configuration on the server, not by a setting in the database, so no sign-up or database change can grant administrator rights.

Isolation between customers

  • Dedicated plan, dedicated machine. Each Dedicated customer gets their own cloud server. Placement is enforced in code and by a unique constraint in the database, so another customer’s app cannot be placed on your server.
  • Builds run under limits. Each build runs with a memory ceiling and a CPU cap, and each running app has its own memory limit and is restarted if it exceeds it. One runaway build cannot take the whole server down.
  • Inputs are never trusted into shell commands. Repository URLs and branch names are checked against a strict format. Your environment variables and custom build commands are encoded before they reach the deploy script, so a quote or semicolon in a value cannot become a command.

Network

  • Your app’s port is not open to the internet. Visitors reach your site only through our HTTPS proxy on ports 80 and 443. The ports apps listen on are closed at the cloud firewall, so nobody can scan a server and reach your app around the proxy.
  • HTTPS everywhere. Certificates for your Kernel6 address and your own domains are issued and renewed automatically by Let’s Encrypt.
  • Domains are verified before they are served. We only serve a hostname after checking that its DNS really points at your server, each hostname can belong to only one customer, and the platform’s own addresses cannot be claimed.
  • Deploys travel over SSH, using keys held per server.

Payments

Card and bank details are entered on Razorpay’s, Stripe’s or Dodo Payments’ own checkout and never reach our servers. Payment notifications from those providers are accepted only with a valid cryptographic signature, so a forged “payment succeeded” message is rejected.

Abuse protection

  • Public forms are rate-limited per IP address and filter out automated submissions.
  • Password resets are limited per account, and a request for an unknown address gets the same response as a known one, so the form cannot be used to find out who has an account.

Your part

  • Use a long, unique password for Kernel6.
  • Keep secrets out of your Git repository. Put them in environment variables, which is what they are for.
  • Keep your app’s dependencies up to date. We run your code as it is.
  • Keep your own copy of anything you cannot afford to lose, including any data your app writes to disk.

Reporting a vulnerability

If you think you have found a security problem in Kernel6, please tell us through the contact form, starting your message with “Security”. Include what you found and how to reproduce it.

  • We will acknowledge your report and keep you updated while we fix it.
  • Please do not access or change other customers’ data, degrade the service, or make the issue public before we have had a reasonable chance to fix it.
  • We will not pursue anyone who reports a vulnerability in good faith and follows these rules.

For how we handle personal data, see our privacy policy.