Platform architecture
One control plane, many engines beneath it
The architectural principle behind WebyneDB is that adding a database engine should be a provider implementation, not a new product. Plans, endpoints, credentials, backups, monitoring and billing are shared; only the engine-specific lifecycle differs.
The four layers
Customer layer
The WebyneDB dashboard and the public API. Everything you can do by clicking, you can do by calling.
- Web dashboard
- Public REST API
- Scoped API keys
Control plane
Authentication, projects, provisioning orchestration, the plan catalog, billing, the backup scheduler, monitoring, alerts, audit logging and AI analysis.
- Provisioning orchestrator
- Job queue with idempotency
- Backup scheduler
- Metrics collector
- Reconciler
- Audit log
Data plane
Your databases. Each runs isolated, with its own storage volume and enforced CPU and memory limits, on Webyne compute nodes.
- Isolated instance per database
- Dedicated storage volume
- Plan-enforced resource limits
- No customer shell access
Infrastructure
Compute nodes, NVMe storage, backup storage, private networking, public ingress, DNS and monitoring.
- Compute nodes
- NVMe storage
- Backup repository
- Private network
- DNS and ingress
Why the separation matters
It is not architectural neatness for its own sake — it changes what happens when something goes wrong.
Your database survives our dashboard
Restarting or upgrading the control plane does not interrupt a single customer database. They are separate processes that keep serving traffic on their own.
Failed operations are recoverable
Provisioning runs as recorded jobs with idempotency keys. If the control plane restarts mid-operation, the job is picked back up rather than leaving an instance stranded half-created.
Reported state matches reality
A reconciler continuously compares what the platform believes about each instance with what the runtime actually reports, and corrects the record rather than showing you a comfortable fiction.
Technology
The blueprint's recommended component for each layer, and what is actually deployed today.
| Layer | Recommended | Deployed today |
|---|---|---|
| Frontend | Next.js + TypeScript | Next.js 16 + TypeScript |
| Core API / orchestrator | Go | TypeScript, isolated for later extraction |
| AI / analytics | Python / FastAPI | TypeScript rule engine + pluggable model |
| Platform metadata DB | PostgreSQL | PostgreSQL |
| Queue / events | NATS or RabbitMQ | Database-backed queue with idempotency keys |
| Secrets | HashiCorp Vault | AES-256-GCM, single swap point for Vault |
| Metrics | Prometheus + Grafana | In-platform collector |
| Logs | Loki | In-platform log store |
| Automation | Ansible + Terraform | Shell provisioning scripts |
| Runtime | Docker, then Kubernetes at scale | Docker |
Where the deployed component differs from the recommendation, it is a deliberate simplification for this stage rather than a permanent decision — each is isolated behind a single module so it can be swapped without touching the rest of the platform.
Want the deeper technical detail?
We are happy to walk your architects through the provisioning path, the job model and the failure cases.