For more than 20 years, the team I am part of has been helping organisations build and operate software platforms. Those two decades have been full of lessons. The most important ones:
- Building software is hard. A system with interdependencies is difficult to create and maintain; without a clear architecture, it is even harder.
- Software creation is more like manufacturing in the physical world than we think: without controlling the factory, you cannot build great products.
- The platform must be another service within the organisation. Its performance directly affects developer effectiveness.
The conclusion is clear: the platform must guarantee self-service and governance at the same time.
For years, we applied these lessons as platform designers and maintainers in different organisations. We soon realised we needed a tool to help us adapt and standardise that work. And that making it open source made sense.
Firestartr is the result.
An open-source project that turns your organisation’s model (domains, systems, components, teams and infrastructure) into the platform’s source of truth. Real self-service + built-in governance.
An explicit model for building your Internal Developer Platform
Any organisation responsible for software will find itself with a collection of repositories, pipelines and deployed environments that, over time and as the team grows, become a maze that is difficult to manage.
One of the main reasons is that the complex network of relationships that naturally forms between all these pieces exists, and only partially, “in the heads” of those who have been around the longest. In other words, these are implicit relationships that can only be understood and known after spending time in the organisation.
- ❌ The “Tribal Knowledge” effect: Onboarding new developers becomes slow and painful. Understanding what a service does or how it connects to others means asking “the people who have been around the longest”.
- ❌ Operational fragility: When a senior engineer leaves the organisation, part of the invisible map of the infrastructure is lost.
- ❌ Fear of change: No one dares to refactor or shut down a component because no one is sure which systems depend on it or what side effects altering or removing it might have.
We have experienced this “opaque culture” firsthand. That is why we designed Firestartr to move relationships out of people’s heads and into the model.
Our approach combines the perspective of DDD (Domain-Driven Design) with the structural hierarchy of the C4 model to achieve modelling similar to Backstage’s software catalog.
- Domains — Areas of responsibility within the organisation.
- Systems — Coordinated groups of software that solve a specific business problem within a domain.
- Components — Atomic pieces of software (usually a repository). They are packaged, deployed, scaled and monitored.
- Teams — Groups of people responsible for the full lifecycle of a system and/or its components.
How is it different from Backstage + Argo + Terraform?
📚 Backstage gives you the catalog.
🔄 Argo CD gives you continuous reconciliation.
🏗️ Terraform gives you the infrastructure.
🧩 Firestartr brings all three together under a single model of ownership and claims.
A change of ownership, a new component or a Terraform workspace is no longer spread across three separate tools: these are declarations that the engine understands and applies consistently.
What about provisioning cloud services?
Terraform has become the lingua franca of cloud provisioning.
Firestartr treats a service (or an inseparable group of services) provisioned with Terraform/OpenTofu as a first-class Terraform Workspace (and models it as such in the organisation’s catalog). Treating Terraform Workspaces as explicit resources in the model bridges the gap between infrastructure and applications:
- ✅ Environment state isolation: Each component explicitly declares its Terraform Workspace (
payment-processor-prod,payment-processor-staging), with an isolated backend state managed by the platform. - ✅ Controlled variable injection: Workspace credentials and environment variables are resolved securely through platform policies, without exposing secrets in application-level repositories.
- ✅ Unified lifecycle: When a component is removed through a claim, its associated Terraform Workspace is destroyed in a controlled way.
This avoids orphaned resources left forgotten in the cloud and continuing to incur costs.
GitOps engine: the heart of the factory
GitOps has become the standard for IDPs. Git as the single source of truth, changes through pull requests and continuous reconciliation.
Firestartr builds its engine on this principle, but deliberately keeps it simple:
- Everything is a claim. A YAML file in a repository declares the intent: a component, system, team or Terraform workspace. There is no hidden state.
- The renderer is a lightweight pipeline. It validates, hydrates and completes each claim with the organisation’s defaults and policies. It produces Custom Resources and catalog entities ready for reconciliation.
- The Operator + Argo CD do the rest. They watch, synchronise and provision. They reuse Kubernetes, Git and OpenTofu instead of reinventing a heavyweight control plane.
The result is an engine anyone can follow:
you declare → it is rendered → it is reconciled → it appears in GitHub and the cloud.
Simple to understand. Lightweight to operate. Complete in what it delivers.
Stitching: weaving together intents from different sources
Our experience with GitOps has taught us three key principles:
- Users should be able to express their intent as briefly as possible, with as few options as possible.
- Defaults are the foundation: they represent the standard, secure and governed architectural blueprint that the platform applies automatically.
- There must be global policies (mandatory for everyone) that no one can override.
Firestartr combines these three declarative sources in a clear order of precedence:
- User — Declares the fundamental intent: create a component, provision a database, add a user to a team…
- Defaults — The platform completes and standardises that declaration with the standard values defined by the organisation.
- Globals — Mandatory directives that take precedence over everything above. They sit at the top of the pyramid and cannot be overridden.
As a result, the actual definition of any artefact comes from these three layers, always respecting their order of precedence. The user writes little; the platform ensures consistency and governance.
Open source and Prefapp’s services
Firestartr is Apache-2.0. All the engine’s code is at:
→ github.com/firestartr-pro/firestartr
Prefapp maintains the project and offers professional services:
design and implementation, feature and policy customisation, support, and ready-to-use skills.
- Firestartr → the code and the model, with no vendor lock-in.
- Prefapp → expertise and contractual outcomes.
If you want to try it, start with the documentation: docs.firestartr.dev.
We can help you implement it; talk to us.