Eating Our Own Dog Food: Axon Ivy @ Axon Ivy 🐶
Every year at Code Camp, we get the chance to step away from the daily sprint rhythm and work on passion projects. Sometimes these projects are experiments, sometimes prototypes, and sometimes they turn into something surprisingly practical.
This year, my project was very practical: I set up an Axon Ivy Engine for our own Core Development team.
Not a demo engine. Not a local test setup that disappears after a few days. A real internal Axon Ivy Engine, running on our team infrastructure, ready to host workflows that support our own daily work.
Why We Needed It 🚀
The original motivation came from a new responsibility I recently took over: vocational education and training of our apprentices.
This summer, a new apprentice started with us, and I have the pleasure of accompanying @ivy-cgr during his training in our development team. His first project is to support our Scrum development process with automation and workflows.
And since we build a process automation platform, the natural question was: Why not build this with Axon Ivy itself?
The idea is simple: create workflows that help us with recurring Scrum activities, internal coordination, or small team processes. But to make that useful, we need a place where these workflows can actually be deployed, tested, and used by the team.
So the Code Camp mission became clear: create our own little Axon Ivy Project World for the Core Development team.
The Setup ⚙️
The engine is defined as infrastructure as code in our internal infrastructure repository. That means the setup is reproducible, reviewable, and can evolve together with the rest of our team services.
The stack is intentionally straightforward:
- Axon Ivy Engine running from our Docker image
- PostgreSQL as the system database
- OpenSearch as the search engine
- SWAG as reverse proxy
- Keycloak integration for our team login
- SMTP configuration for mail notifications
- Persistent Docker volumes for configuration, data, applications, database, and search indexes
The engine is reachable via our internal team domain and integrated with our existing identity provider. From a user perspective, it feels like any other team service: open the URL, log in, start working.
From an admin perspective, it is also a valuable little playground. The configuration lives in ivy.yaml, the deployment in compose.yaml, and Ansible takes care of getting the files to the right place. No clicking together a server by hand and hoping we remember how it was done later.
Using Ivy to Improve Ivy 🪞
What I like most about this project is that it is not only infrastructure.
It gives us a place where we can use Axon Ivy the way our users and customers do. As developers, we often spend most of our time deep inside the product: APIs, runtime behavior, build pipelines, tests, migration logic, performance, UI components, and many other details.
That is important work. But it is not always the same perspective as running an engine, deploying real projects, configuring authentication, handling mail, checking logs, managing data, or thinking about how a team actually uses a process application every day.
By operating our own engine, we get closer to that perspective.
We can notice friction earlier. We can see which configuration options are easy to understand and which ones still require too much product knowledge. We can experience the difference between “this feature works” and “this feature is pleasant to operate.” And we can do all that with a system we genuinely care about, because it supports our own work.
In other words: we get to eat our own dog food. Ideally with good seasoning.
First Use Case: Scrum Management 📋
The first project planned for the engine is the apprentice project around Scrum Management.
There are many small things in a development process that are important, but also repetitive. Preparing sprint information and resources, collecting input, coordinating reviews, supporting retrospectives, or reminding people about tasks.
These are exactly the kinds of workflows where Axon Ivy can shine. They are not necessarily huge business processes, but they connect people, tasks, decisions, forms, notifications, and data.
For an apprentice project, this is also a great learning opportunity. It touches many relevant topics at once:
- Modeling business processes
- Designing user interactions
- Working with data
- Deploying to a real engine
- Receiving feedback from real users
- Improving the workflow iteratively
That last part is especially valuable. A workflow used by our own team gives fast and honest feedback.
More Ideas Are Already Appearing 💡
Once people heard that we now have an internal engine, new ideas started to appear quickly.
One example came from our backoffice and finance team: a travel expense claim process. That is a perfect candidate for process automation. It involves forms, approvals, documents, responsibilities, traceability, and notifications. All the classic ingredients.
And there are many more possible use cases, just to name a few:
- Onboarding workflows for new team members or apprentices
- Recurring maintenance checklists
- Release preparation helpers
- AI Agents
- Small tools that are too specific for a standard SaaS product, but perfect for Ivy
The nice thing is that we now have a place to try these ideas without turning each of them into a big infrastructure discussion first.
Lessons Learned 📚
Infrastructure Should Be Boring
For this project, boring is a compliment.
Docker Compose, Ansible, PostgreSQL, OpenSearch, reverse proxy, SSO, mail. None of these pieces are especially exotic, and that is exactly the point. The goal was not to invent something new, but to create a solid state-of-the-art place where process projects can live.
Running the Product Changes the Perspective
Even for us as core developers, operating an engine is different from implementing one feature inside it. You care about startup behavior, configuration clarity, logs, volumes, backups, authentication, certificates, and upgrades in a much more direct way.
That perspective is healthy for product development.
A Real Deployment Makes Apprentice Projects More Meaningful
It is motivating when a first project is not just an exercise, but something the team can actually use. The deployment target already exists, the users are nearby, and the feedback loop is short.
Small Internal Processes Add Up
Not every workflow needs to be a large enterprise process. Many useful automations are small. But if they remove friction from recurring work, they can still have a meaningful impact.
What’s Next? 🔮
The next step is to deploy the first Scrum Management workflow and let the team use it for real. From there, we can improve both the workflow and the engine setup based on actual usage.
I also want to keep the infrastructure close to how we would recommend running such a setup: reproducible, documented, backed by persistent data, connected to identity management, and easy enough to understand when someone else looks at it later.
I hope this internal engine becomes a small innovation platform for our team. A place where apprentices, developers, and colleagues can turn process ideas into something usable.
Code Camp gave us the time to build the foundation. Now we get to see what grows on top of it.
From the mountains to our own little Ivy runtime,
Lukas ✍️
