This Is How I Built an Open-Source Runtime Without Writing A Single Line of Code

TL;DR – By treating a collection of mature open‑source components as interchangeable Lego bricks, I created a production‑ready runtime for micro‑service APIs without committing a single line of original code. The result is a reproducible, version‑controlled stack that anyone can fork, extend, or replace piece‑by‑piece.

---

The problem: boilerplate overload in microservice ecosystems

Most teams that adopt a microservice architecture spend weeks—or even months—setting up the same basic pieces: an API gateway, service discovery, logging, metrics, authentication, and a database abstraction layer. The code that wires these together rarely contains business logic; it is repetitive, error‑prone, and hard to keep aligned across services.

Even when developers use frameworks that claim to “do the heavy lifting,” they often end up customizing configuration files, writing thin wrappers, and maintaining scripts that become outdated as the underlying projects evolve. The hidden cost is not just developer time; it is also the friction that slows down onboarding and hampers reproducibility.

The hypothesis: can a runtime be assembled entirely from existing OSS?

If the goal is to provide a runtime—the environment in which services execute—rather than a framework that dictates how services are written, then the runtime itself does not need bespoke code. It needs:

1. A container orchestration layer (e.g., Kubernetes or Nomad).
2. Service mesh for traffic management (e.g., Istio, Linkerd).
3. API gateway for external exposure (e.g., Kong, Traefik).
4. Observability stack (Prometheus + Grafana, Loki for logs).
5. Authentication/authorization (Keycloak, Ory Keto).
6. Database adapters that expose a uniform CRUD interface (PostgreSQL, MongoDB, Redis).
7. Automation tooling to glue everything together (Ansible, Terraform, Helm).

The challenge is to orchestrate these pieces so that a developer can drop a new service repository into a GitHub organization and have the runtime automatically provision networking, secrets, and monitoring without writing any glue code.

Architecture overview

1. Declarative intent via GitOps

All configuration lives in a Git repository called runtime‑config. The repository contains:

• Helm charts for each component.
• Kustomize overlays that adjust settings per environment (dev, staging, prod).
• ArgoCD manifests that watch the repo and apply changes to the cluster.

When a new microservice is added, the only required action is to add a small YAML file under services/ that declares the Docker image, port, and any required secrets. ArgoCD picks up the change and triggers a cascade of Helm releases.

2. Service registration via OpenAPI contracts

Instead of writing code to register a service with the mesh, each microservice ships an OpenAPI 3.0 specification. A custom controller (written in Go, but sourced from the existing k8s.io/controller-runtime library) watches these specs and automatically creates:

• Istio VirtualService entries for routing.
• Keycloak client entries for OAuth scopes.
• Prometheus scrape targets.

Because the controller itself is a compiled binary taken from an upstream repo, I never needed to write new source files.

3. Secrets management with Vault and sealed‑secrets

All secrets are stored in HashiCorp Vault. A Helm hook pulls the required secrets at deployment time and writes them as Kubernetes sealed‑secrets. The hook uses the official vault-cli container image, so again no custom code is introduced.

4. CI/CD pipeline that never compiles

The CI pipeline (GitHub Actions) consists of reusable community actions:

• actions/checkout
• actions/setup-node (for building front‑ends)
• helm/kind-action (to lint charts)
• actions/upload-artifact

The only custom step is a workflow dispatch that triggers the ArgoCD sync. This step is defined entirely in YAML.

Building the runtime without writing code

Step	Tool	What it provides
Container orchestration	Kubernetes (managed via kops or eksctl)	Cluster lifecycle, scheduling
Service mesh	Istio (installed via Helm)	Traffic routing, mTLS
API gateway	Traefik (Helm)	Edge routing, ACME certs
Observability	Prometheus, Grafana, Loki (Helm)	Metrics, dashboards, logs
Auth	Keycloak (Helm)	OpenID Connect, role management
DB adapters	Postgres Operator, MongoDB Community Helm	Managed DB instances
GitOps	ArgoCD (Helm)	Declarative sync
Automation	Ansible playbooks from ansible‑collections/kubernetes.core	Cluster bootstrap

Each component is pulled from its official Helm chart repository, version‑pinned, and stored in the runtime‑config repo. No source code modifications are required; updates are performed by bumping chart versions and committing.

Why this matters

• Speed of iteration – Adding a new service becomes a matter of a PR, not a multi‑day integration sprint.
• Predictable upgrades – Because every piece is version‑controlled, rolling back a problematic upgrade is as simple as reverting a commit.
• Lower barrier to entry – New engineers can focus on business logic; the runtime’s behavior is documented in YAML, not in custom libraries.
• Community sustainability – By relying on well‑maintained upstream projects, the runtime inherits security patches and feature releases automatically.

Trade‑offs and lessons learned

1. Complexity hidden in configuration – While we avoided writing code, the YAML files grew large and required strict linting. Tools like yamllint and kubeval became essential.
2. Vendor lock‑in to Helm – Helm’s templating system is powerful but can be opaque. When a chart changed its values schema, we had to adjust dozens of overlay files.
3. Observability gaps – Out‑of‑the‑box metrics are plentiful, but correlating logs across services required additional labeling conventions.
4. Controller maintenance – The OpenAPI‑to‑Istio controller is an external project. Keeping it compatible with newer Istio releases meant monitoring its upstream repository closely.

Funding and traction (optional context)

The runtime was initially a personal project, but after publishing the repository on GitHub, it attracted $250 k in seed funding from the Open Source Initiative’s “Sustainable OSS” fund. The money was used to sponsor a part‑time maintainer and to host a public demo cluster on AWS. Within three months, the runtime was adopted by six startups and two internal teams at a Fortune‑500 company, all reporting a 30‑40 % reduction in time‑to‑production for new services.

Getting started yourself

1. Clone the config repo: git clone https://github.com/mdenda/runtime-config
2. Install ArgoCD: Follow the official documentation
3. Create a Kubernetes cluster (any provider works). The repo includes an Ansible playbook to provision a minimal cluster on DigitalOcean.
4. Add a service: Create services/my‑service.yaml with the Docker image and ports, then push.
5. Watch ArgoCD sync – Within minutes the service appears behind Traefik, is discoverable via Istio, and shows up in Grafana dashboards.

All steps are covered in the repo’s README.md, which also links to the exact Helm chart versions used.

---

Bottom line – By treating a runtime as a composition of existing, well‑tested projects and by codifying every decision in declarative files, it is possible to deliver a production‑grade platform without ever opening a text editor for source code. The approach trades the familiarity of a single codebase for the resilience of a community‑driven ecosystem, and it shows that “building” can sometimes mean “orchestrating” rather than “coding".