Built with isolation
as the default.

Kubernetes platform

KoedoDB runs its customer platform on Kubernetes. Kubernetes provides the scheduling, service discovery, workload boundaries, and policy controls used to operate project services.

Project isolation

Projects are placed in separate Kubernetes namespaces with resource limits and default-deny network policies. Each project’s database runs on its own dedicated microVM, isolated from other customers. Functions and static hosting share infrastructure, and each customer’s code runs in its own sandbox. Customer application code runs inside a lightweight virtual machine or sandbox. None of these workloads is given Kubernetes API access, host networking, privileged containers, or host filesystem mounts.

Database and access controls

Each project has isolated database and authentication configuration. Row Level Security is available for application data and remains the customer's responsibility to configure correctly. Operational administration is performed through platform services rather than direct customer access to infrastructure databases.

Secrets and transport

Secrets are encrypted before they are stored. Each project has its own encryption key, and each secret is encrypted separately (AES-256-GCM, bound to its project and its name, so a stored value cannot be moved to another project or another secret). Project keys are in turn encrypted with a master key that only the platform component delivering secrets to your project's host can use. The customer-facing API and the operator interface cannot decrypt a secret.

Service credentials are mounted only into the workloads that need them. Connections to public endpoints use TLS. Internal platform communication is restricted by network policy, and the agent on each host authenticates to the platform with a certificate that identifies that host and no other.

Outbound network access

Customer workloads start with restricted outbound access. Compute services can reach the internet on web and mail ports only, and databases can reach only DNS and their backup storage. Access to other projects, platform control services, node addresses, metadata endpoints, and private network ranges is blocked. We monitor unusual outbound traffic and may throttle or restrict a project that presents an abuse or security risk.

Administrative access

SSH accepts keys only: password login and root login are disabled. Every public network interface is filtered: everything is denied by default, and the only exceptions are web traffic from Cloudflare and the database ports (see below for what protects them). Our servers are administered only through a dedicated, private maintenance connection; no management port is open to the internet.

Server hardening

Security updates are applied to our servers automatically. Repeated failed connections to the database ports are blocked. The components that handle customer traffic run with the permissions they need and no more, and each server's agent authenticates to the platform with its own certificate.

Detection and alerts

A change to an administrator's SSH keys on a server, a login through the hosting provider's emergency console, and the failure of a server's agent each send an alert to the operator at once.

Supply chain

The software we run is pinned to specific versions. Container images are pinned by digest, and downloaded components are checked against a checksum or a signature before they are installed. For key components we keep a mirror of the upstream source, so that an upstream repository being removed or rewritten does not stop us.

Logs

System logs are kept on each server across restarts, with a size limit. We are building a central log host where the servers' logs will be collected, so that what happened before an incident can be read even if a server is lost. Until then the logs stay on the servers.

DDoS protection

Web traffic goes through Cloudflare. The API of your project, your site, and your custom domains are served behind Cloudflare’s network, which filters distributed denial-of-service attacks before they reach our servers. The servers accept web traffic from Cloudflare only.

Database connections cannot. A database connection is not web traffic, so it cannot pass through that protection. We limit how fast one address may connect and block addresses that keep failing, but we say plainly that a very large attack on the database ports is a risk we accept for now.

Backups and recovery

Every plan includes Point-in-Time Recovery. We take a physical backup of your database every day and archive the write-ahead log at least hourly, and keep both for seven days, so you can restore to a chosen hourly point in that window; data written in the last hour before a host failure may not be recoverable. Separately, we take a daily logical dump, encrypted and kept in a separate bucket with its own credentials, so that a mistake or a compromise in one backup system does not take the other with it. A logical dump exports your schema and data and does not depend on the physical format; restoring from it rebuilds the database, which is slower, so it is the last resort rather than the usual path. Backups reduce risk but are not a substitute for keeping your own exports of critical data, and we do not guarantee a specific recovery time.

Security updates

We watch the security advisories of the software we run, and write down what we updated and when on the Security updates page. Operating-system security updates are applied automatically. For other software, we aim to apply critical security fixes within 48 hours. This is a goal and not a guarantee: a fix has to be tested before it goes on servers that hold customer data, and some updates need a planned maintenance window.

Report a vulnerability

Please do not disclose suspected vulnerabilities publicly before we have had a chance to investigate. Send a concise report, reproduction steps, and impact assessment to security@koedodb.com. The same contact is published in machine-readable form at /.well-known/security.txt.

Report abuse

If a site or API hosted on KoedoDB, including any address under koedodb.dev or koedodb.net, is used for phishing, malware, spam, or other abuse, write to abuse@koedodb.com with the address and a short description. We read this inbox and act on reports of abuse on our platform. For legal requests, write to legal@koedodb.com.