01
Every repository invents its own way of working.
Different CI/CD, release and configuration patterns for problems that should be solved once. Each team ends up maintaining its own solutions, and shared improvements take longer to reach everyone.
The platform that makes your organization explicit
Your IDP tailored to your need
Firestartr is an open-source framework for building internal developer platforms. It connects domains, systems, components, teams and infrastructure so your platform can create, deploy and evolve software with clear rules.
firestartr
commercedomain
checkout-systemsystem
paymentscomponent
checkout-teamowns checkout-system
one modelmany consistent outcomes
One model for development, platform and infrastructure
When software grows
Organizations lose the map before they lose control
Firestartr starts by making your software visible. Then it turns that knowledge into repeatable, reviewable automation.
02
Architecture stops having recognizable boundaries.
Systems and dependencies exist, but nobody shares a clear view of how they fit together. Without that map, understanding the impact of a change or who it affects means rebuilding the context every time.
03
Responsibility becomes diffuse.
When ownership, permissions and infrastructure live apart, operating becomes slow and risky. Decisions get stuck, and resolving an incident can start with figuring out who should act.
The model
From business domains to deployed software
Firestartr organizes software around the same boundaries the business recognizes. Each level gives context to the next.
commercedomain
inventory-systemsystem
catalogcomponent
checkout-systemsystem
paymentscomponent
Owner: checkout-team
An e-commerce platform
Domains
Group the systems serving one part of the business.
Systems
Define functional boundaries with clear responsibility.
Components
Connect a software unit to its repository.
Teams
Make ownership of every component visible.
Features
Add reusable capabilities to a repository.
Infrastructure
Keep supporting resources beside the software using them.
The platform in action
Connecting the dots
Infrastructure repositories define the platform. Firestartr interprets those inputs, scaffolds code and state repositories, and connects desired state to the runtime.
Three surfaces, one model
Work where your team already works
GitHub, Firestartr Portal and Skill express different instructions, but they all act on the same representation of your organization.
GitHubCode, pull requests and workflows
Repositories, reviews and workflows live here, applying changes to the model.
Firestartr PortalCatalog, ownership and self-service
Browse the catalog, find ownership, and provision or update resources through guided flows.
SkillConversational instructions
Describe a change in plain language: an agent interprets your organization and safely runs Firestartr operations.
Minimal intrusion into your organization
Firestartr fits the tools and workflows you already have
Your team keeps working in GitHub and Backstage. Firestartr connects those surfaces through a shared model and adds automation with repositories, workflows and pull requests, without imposing another place to work.
Use the tools you know
GitHub, Backstage and Skill connect to the same model.
Integrate through repositories
Configuration and workflows live in your organization’s repositories.
Keep reviews in the loop
Changes are validated and can be reviewed before they are applied.
Agents with guardrails
Let your agents move fast. Firestartr keeps the rules in place.
Your agents work against your organization’s map instead of guessing how it is structured. Claims go through deterministic policy checks, and changes follow reviewable flows such as pull requests, keeping your team in control before they are applied.
From intent to change
Automation you can review
An instruction does not jump straight to production. Firestartr interprets it against the map, generates the change and keeps human review in the flow.
- 01Instruction
Describe the change your team needs.
- 02Firestartr
Place the change in your organization’s context.
- 03Claim validation
Check the rules before proposing changes.
- 04Human checkpointPull request
Your team reviews and approves before applying.
- 05Provisioned resource
The approved state reaches your platform.
Self-service with guardrails
Development teams move faster. Platform teams keep control
Provision repositories, systems, teams and workspaces through a guided flow: configure, review, create and track progress.
Read the documentation
Features
Do not deliver empty repositories. Deliver capabilities
A Feature composes the files, workflows and configuration a component needs. The platform evolves without repeating work for every team.
- Builds and releases
- Terraform and cloud resources
- Argo CD and GitOps
- Secrets and documentation
End-to-end GitOps
Every change has a place, a review and a desired state
From a new image to an infrastructure update, Firestartr keeps changes in Git and carries them to environments through a traceable flow.
$ firestartr-cli apply --claim payments
✓ claim validated against policy
✓ pull request opened for review
◌ waiting for merge
→ argo cd syncs desired state
You own the state
Configuration and desired state live in your Git repositories
Your organization’s configuration and state repositories are the source of truth. Changes are versioned and reviewable; depending on the workflow, pipelines apply them or Argo CD syncs them from Git.
Your repository, your history
Application and infrastructure configuration stays versioned in Git.
Changes you can review
Pull requests show what will change before you approve it.
Deploy from declared state
Workflows or Argo CD apply the state you have defined.
Operable governance
Standardize without turning the platform into a black box
01
Rego policies to validate claims
Rules check each change before it is accepted, preventing configurations that break your standards.
02
Pull requests as a review point
Changes stay visible to the team, who can review and approve them before they are applied.
03
OIDC instead of long-lived cloud credentials
Federated identity grants temporary access without storing long-lived keys.
04
Drift detection and synchronization
Compare actual and desired state to spot differences and restore the declared configuration.
05
Operations on one resource or the whole fleet
Apply the same change consistently, whether it targets a single resource or many.