Questions we hear
Short answers about what Joomiz is, what it is not, and how it fits next to the tools you already use.
Compared with other tools
Isn't this just Terraform?
Joomiz borrowed the plan and apply steps from Terraform on purpose. Terraform is a tool for describing infrastructure in code. Joomiz does a different job. A feature team describes what its service needs. The platform team decides how that is provided. The two can work together: a provisioner can start a pipeline that runs Terraform.
| Terraform | Joomiz | |
|---|---|---|
| What the file describes | Infrastructure resources | What one application needs |
| Who offers the building blocks | Whoever writes the configuration | The platform team, as a catalog of types |
| Where the state lives | In a state file or a backend you set up | In the control plane |
| Preview before a change | terraform plan | joomiz plan |
| Who is recorded | Depends on your setup | The person, in a run and an audit trail |
| Can they work together | Yes: a pipeline can run Terraform | Yes: a provisioner can start that pipeline |
How is this different from a developer portal like Backstage?
Backstage is an open-source framework for building a developer portal. Joomiz is not a portal. It is a file, the Joomiz CLI (command line interface) and a control plane. The control plane checks the file, shows a plan, makes the change and records a run. A portal and Joomiz can run together.
Is it like Crossplane or a Kubernetes operator?
No. Crossplane and operators extend Kubernetes. They usually watch resources and keep them in the wanted state all the time. Joomiz does not use Kubernetes custom resources. It acts when someone runs plan or apply, and it checks for drift during a plan. Kubernetes is one place where a service can run.
For feature teams
Do developers need to learn infrastructure to write a joomiz.yaml?
Not the tools behind it. A developer names a type, such as a PostgreSQL database, and sets a few values, such as the size. The platform team decides how it is built. The editor tooling offers completion and checks. The command joomiz validate finds mistakes. The command joomiz plan shows the effect before anything changes.
Which languages and platforms does it support?
Your platform team decides. Joomiz describes what a service needs, not how it is built. The platform team sets the golden paths and the types your teams can request, so it sets the languages. The platform team can reuse the pipelines and Terraform code that already create your resources, or build new provisioners and plug them into the platform.
What happens if an apply fails halfway?
Joomiz does not undo the changes that worked. The run gets the status partially_applied, and the output shows which resource failed. Fix the cause and run apply again. Repeating an apply is safe while nobody else applies to that environment. If someone does, Joomiz refuses the old plan as stale, and you plan again.
Can two people apply to the same environment at the same time?
No. Only one apply can be active for each application and environment. Joomiz refuses a second apply at once and names the run that holds the lock. Plans are never blocked. Other environments and other applications are not affected. If an apply gets stuck, a person with the operator role can release the lock.
For platform teams
Do we have to replace our pipelines and Terraform code?
No. A provisioner is a service that does the real work, and it can use what you already have. The Azure DevOps pipeline provisioner starts a pipeline that you wrote, for example one that runs terraform apply. It reports the result back to Joomiz. For other tools, you can write your own provisioner.
Read more: The provisioners for Azure DevOps and Cloud Foundry
How do we add a building block of our own?
A building block is a type plus a provisioner. You write the provisioner with the starter library, or with any service that follows the OpenAPI contract. You then register it with the control plane. Today a new type arrives with a new version of the control plane. Talk to us about adding one.
How does Joomiz find drift?
During a plan, the control plane asks each provisioner what really exists. It compares the answer with what it recorded at the last apply. The plan then shows each difference, and an apply puts the values of the file back. If a provisioner cannot read a resource, the plan says so and does not guess.
Security
Does Joomiz see our passwords?
A joomiz.yaml file never holds a secret. A provisioner stores a secret, such as a database password, in a vault. It reports only the address of the secret. The control plane accepts a sensitive output only when it is an address, and it refuses a raw value. Sign-in passwords stay with your identity provider.
How do people sign in, and who may do what?
People sign in with your identity provider, using OAuth 2.0. The Joomiz CLI shows a code that you enter in a browser. The dashboard uses a normal browser sign-in. A pipeline uses a token. The role owner:<team> lets a person act for one team. The role operator is for the platform team.
Can we prove who changed what?
Yes. Every plan and every apply is saved as a run. A separate audit trail records who registered an application, who started an apply, and who released a stuck run. It records the ID of the person, not a name. The trail is append-only. You set how long it is kept.
Getting started
How can we try it?
Try the simulator on this site. It replays the real CLI and editor in four short exercises. To see Joomiz on your own platform, talk to us. The Joomiz CLI is not a public download yet.
What does it cost, and who runs it?
Your platform team deploys and runs the control plane, and the documentation shows how. For price, licence terms and support, talk to us.
Still have a question?
Tell us about your platform and what your teams ship.
Email us