Security

This page describes how Kuberns protects the data you give us and the workloads we run on your behalf. It is written for the people who have to answer for that choice — founders, engineering leads, and whoever reviews a vendor before it is signed.

It does not describe how to secure the application you deploy on Kuberns. That is covered in our security documentation, and the split between the two is set out in section 11.

We have deliberately kept this page to things that are true today. We hold no SOC 2 or ISO 27001 certification, and we do not claim our software is free of vulnerabilities — no one can. What follows is the set of controls we actually run.

All traffic to Kuberns is served over TLS, with HTTP Strict Transport Security enabled across the domain and its subdomains.

At rest, we apply field-level encryption to the data that would do the most damage if it leaked: names, email addresses, company names, OAuth tokens, autopay tokens, environment variables, database credentials, and SSL private keys.

To be precise about the limit of that: build logs, deployment activity and transaction metadata are stored without field-level encryption. They sit behind the same access controls, but we would rather state the boundary than imply a blanket claim.

Kuberns runs on AWS. Provisioning, deployment and teardown are orchestrated through IAM-scoped roles rather than long-lived shared credentials, and temporary infrastructure created during a deployment is cleaned up when the deployment finishes.

Service health is monitored continuously, and healing events are recorded so a recovery can be traced after the fact.

Within your account, access is role-based. Owner, Co-Owner and member roles carry different permissions, and you control who holds which.

On our side, production access is limited to the company owner and is protected by two-factor authentication. Engineering work does not require standing production access.

Authentication to Kuberns itself runs over OAuth, and GitHub webhook payloads are verified by HMAC signature before they are acted on.

Our backend runs static analysis on every change through SonarQube, with a quality gate that blocks a merge on new issues, and security hotspots reviewed rather than dismissed.

Our web properties are served with a standard set of hardening headers: HSTS with preload, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a strict referrer policy, and a permissions policy that denies camera, microphone and geolocation by default.

Managed databases are backed up automatically once a day through AWS, and you can restore from a backup yourself from the dashboard without raising a ticket.

Because backups run daily, a restore returns your database to its state at the last backup — so up to a day of writes can be lost in a recovery. If your workload cannot tolerate that, take your own more frequent backups as well.

Our control plane — accounts, billing and platform metadata — is hosted in India. AI processing for the deployment agent happens in the United States. Your deployed applications run in the region you choose.

Every third party that receives personal data is listed, with what it receives and where it processes it, on our subprocessors page.

Employees complete security training, and we run background checks as part of hiring. Access to customer data is granted on need, not by default.

We maintain a written breach notification runbook. It names who declares an incident, who investigates it, who notifies, and who records it, and it covers breaches that originate at one of our providers as well as our own.

Where a breach affects personal data, we notify the Data Protection Board of India and every affected person, as the Digital Personal Data Protection Act requires. We acknowledge reports within 24 hours and aim to resolve within 15 days.

If you have found a security problem in Kuberns, please tell us at [email protected]. A machine-readable copy of this contact is published at /.well-known/security.txt.

Helpful reports usually include:

• What the issue is and which part of the product it affects.
• The steps needed to reproduce it.
• What an attacker could do with it.

We aim to acknowledge every report within three business days and will keep you updated while we work on a fix. We will not pursue legal action against anyone who reports a problem in good faith, stays within their own test account, and does not access, modify or destroy other people's data or degrade the service for others.

We do not currently run a paid bug bounty, so please do not expect a reward. We will credit you if you would like us to.

We are responsible for the platform: the infrastructure we provision, the orchestration that runs your deployments, and the data you give us to operate your account.

You remain responsible for what you deploy, which means:

• Your application code and its dependencies.
• Secrets and external credentials you supply.
• Who you grant access to within your account.
• Classification, retention and backups of the data your application handles.
• Any compliance obligation specific to your workload.

The practical guidance for all of this is in our security documentation.