Codafords runs app hosting, serverless functions, managed databases and object storage on a private, self-managed cluster we own end to end. Nothing shared with another provider. Every layer chosen to make a real multi-tenant cloud possible on infrastructure we control.
Five layers, each purpose-built rather than one undifferentiated pool — this is what makes tenant isolation and platform stability possible at the same time. Traffic flows top to bottom; a tenant’s code flows bottom to top.
Every route on the platform enters through the default ingress class. Real TLS certificates are issued automatically via Let’s Encrypt — for platform URLs and tenant custom domains alike.
The API and scheduler pool runs the control plane. Tenant-facing auth handles self-service signup, login, session management and account recovery, paired with OAuth2/OIDC token issuance — both dedicated exclusively to Codafords.
Everything is split into distinct, isolated pools rather than one undifferentiated pool. A cluster policy automatically enforces node affinity, so tenant workloads run only in the tenant pool — physically separated from platform infrastructure.
Two separate storage systems, each matched to what it is actually good at: block storage for anything needing a real POSIX-consistent low-latency disk, and object storage for anything better modelled as immutable blobs.
A user with three projects has three independently-quota’d, independently-isolated workloads. NetworkPolicies restrict pod-to-pod traffic across tenant boundaries, and event-driven autoscaling scales HTTP workloads down to zero when idle.
Event-driven autoscaling drives both tenant apps and CodaFunctions — chosen because standard autoscaling cannot scale to zero, but HTTP-based scaling can, which matters on a platform hosting many low-traffic apps.
An admission-time check verifies real cluster headroom before a new tenant is provisioned, protecting the whole tenant pool from oversubscription. Pilot stage.
Every credential generated anywhere in the project is logged in a single access-controlled, git-ignored record — enforced consistently across the whole build.
A GitHub repository through a real GitHub App integration, or a direct push to Codafords-hosted GitLab.
Automatic build detection with no Dockerfile required, plus a custom Next.js buildpack.
A push triggers a real build on the DevOps pool, isolated from tenant workloads.
The built image lands in the platform’s own container registry, scoped per tenant.
Rolled out into the tenant pool, routed through ingress, TLS issued, live status reported.
Not a roadmap slide — every product below has been run end to end on the running cluster, not demoed against a mock.
The foundation everything else builds on: push code, get a running, publicly-reachable application with zero infrastructure knowledge required.
Deploy a single function instead of a whole app, triggered however makes sense for the workload.
A real “provision a production-grade database in minutes” experience — a dedicated instance per tenant, never a shared multi-tenant schema.
An S3-like storage service, API-driven by design — tenants never receive a standing storage credential.
One platform experience covering everything a tenant runs, with real self-service throughout.
Every layer above is running right now. Connect a repository and get a live URL in about ninety seconds.