Gregor Woitczyk · Popetto
I want to understand how things work. Their parts, their rules, how they fit together.
From that understanding, I build software, systems and workflows that work reliably and leave time for new ideas.
Software & systems AI & automation Creativity & responsibility
01 / Approach
Yesterday, today, tomorrow and beyond. Four perspectives from my practice: understand, stabilise, transform and automate.
One approach. Three projects of my own.
In Ansible-Hub, I connect server configuration, controlled changes and checks of the actual state. The firewall is a concrete example: a rule in a repository and an effective rule on a server are two different things.
Select a point. Motion pauses. Read the step ↓
Beam = project progressFour perspectives on the same project. These steps make tasks and decisions from my work concrete; PDCA helps organise them. In practice, each step can take several rounds. About the PDCA cycle ↗
Identify the parts, rules and connections.
For a firewall, I need to know more than what is in its configuration file. I distinguish the intended state, the deployed configuration and the rules that are actually active.
In the project: The checking workflow compares intended rules, configuration and active state.
A concrete question instead of an assumption that everything matches.
Ansible-Hub has a separate checking workflow that leaves managed firewall rules unchanged. It gathers the different states before a finding becomes a change.
In the project: Checking and applying changes are separate operations.
An inventory of the state that can support further decisions.
Not every difference means the same failure. The comparison distinguishes an exact match, additional rules and missing required state.
In the project: The result categories distinguish these cases and keep extra rules visible.
A finding that I can interpret deliberately.
A check applies to the selected systems that are included in its scope. Servers are deliberately enrolled in Ansible-Hub’s checks; a run with no matching targets confirms no server state.
In the project: The target group and an additional host selection bound each run.
Clarity about what a result applies to.
Build a dependable foundation.
Changes to access rules must not accidentally affect every system. SSH changes require an explicit target selection, and the command rejects unrestricted selection patterns.
In the project: The SSH target selection is checked before execution.
A specific intervention aimed at a specific target.
Preparation, connectivity and changes have separate steps. Ansible-Hub provides previews and deliberate application; local changes require explicit enablement.
In the project: Local changes are disabled by default while inspection remains available.
A deliberate transition from inspection to intervention.
Before changing SSH configuration, the role checks for the intended operations account and a valid public key. It refuses the change if that foundation is missing.
In the project: Account and key checks precede application of the SSH configuration.
A checked prerequisite instead of a blind configuration change.
A failed run is part of the operational history too. The shared command records execution, output, completion and exit status.
In the project: Run logs are part of the wrapper; CI runs also carry their job context.
A basis for handover and diagnosis.
Bring things together, reshape them and make them understandable.
Not every server needs the same configuration. I group shared tasks into roles and express differences through group and host settings.
In the project: Roles for the base system, Docker, SSH and the firewall have configurable defaults.
A shared structure with explicitly described differences.
Two separate lists of intended firewall rules could drift apart. The checking workflow therefore derives the expected state from the same templates and settings used for deployment.
In the project: Deployment and comparison use the same role templates and variables.
A consolidated definition of the intended state.
An exception must mean the same thing during setup and inspection. In Ansible-Hub, these settings belong in the shared group or host configuration.
In the project: The firewall documentation identifies the shared source of the expected state.
Fewer conflicting definitions of the same operational rule.
An executable workflow also needs a clear explanation. Operational guides sit alongside the roles and describe commands, prerequisites and limitations.
In the project: Firewall and SSH documentation describe their workflows and current implementation scope.
Operational knowledge can be read, checked and developed further.
Hand proven routines over to tools.
Collect configuration, compare rules and record the finding: these recurring steps can be described precisely. They form a useful, bounded automation task.
In the project: The firewall check is available as a dedicated Ansible workflow.
A clear scope for reducing repeated manual work.
The checking workflow generates the expected state, reads configuration and active rules, and performs the comparison. One deliberate command handles the individual technical steps.
In the project: The same workflow is documented for local use and a manually triggered CI job.
The check can be repeated without assembling each step again.
A successful overall pipeline does not answer every operational question. Manual checking jobs and their results must be reviewed individually; the finding remains an output in its own right.
In the project: A concise finding and the full execution log are kept separately.
Repeatable technical work with a result that can be assessed.
The tool handles collection and comparison. Which discrepancy calls for a change, and when to intervene, remain deliberate operational decisions.
In the project: Check scope and the change path remain explicit choices; inspection does not repair automatically.
More attention for causes, decisions and the next improvement.
Another perspective
Problems do not stand still. While I work on a task, the situation changes. Like a solar system in motion, the helix shows both: the path of the task and my work around it.
Select a point. Motion pauses. Read the step ↓
Orbit = project progressFour perspectives on the same project. These steps make tasks and decisions from my work concrete; PDCA helps organise them. In practice, each step can take several rounds. About the PDCA cycle ↗
Identify the parts, rules and connections.
For a firewall, I need to know more than what is in its configuration file. I distinguish the intended state, the deployed configuration and the rules that are actually active.
In the project: The checking workflow compares intended rules, configuration and active state.
A concrete question instead of an assumption that everything matches.
Ansible-Hub has a separate checking workflow that leaves managed firewall rules unchanged. It gathers the different states before a finding becomes a change.
In the project: Checking and applying changes are separate operations.
An inventory of the state that can support further decisions.
Not every difference means the same failure. The comparison distinguishes an exact match, additional rules and missing required state.
In the project: The result categories distinguish these cases and keep extra rules visible.
A finding that I can interpret deliberately.
A check applies to the selected systems that are included in its scope. Servers are deliberately enrolled in Ansible-Hub’s checks; a run with no matching targets confirms no server state.
In the project: The target group and an additional host selection bound each run.
Clarity about what a result applies to.
Build a dependable foundation.
Changes to access rules must not accidentally affect every system. SSH changes require an explicit target selection, and the command rejects unrestricted selection patterns.
In the project: The SSH target selection is checked before execution.
A specific intervention aimed at a specific target.
Preparation, connectivity and changes have separate steps. Ansible-Hub provides previews and deliberate application; local changes require explicit enablement.
In the project: Local changes are disabled by default while inspection remains available.
A deliberate transition from inspection to intervention.
Before changing SSH configuration, the role checks for the intended operations account and a valid public key. It refuses the change if that foundation is missing.
In the project: Account and key checks precede application of the SSH configuration.
A checked prerequisite instead of a blind configuration change.
A failed run is part of the operational history too. The shared command records execution, output, completion and exit status.
In the project: Run logs are part of the wrapper; CI runs also carry their job context.
A basis for handover and diagnosis.
Bring things together, reshape them and make them understandable.
Not every server needs the same configuration. I group shared tasks into roles and express differences through group and host settings.
In the project: Roles for the base system, Docker, SSH and the firewall have configurable defaults.
A shared structure with explicitly described differences.
Two separate lists of intended firewall rules could drift apart. The checking workflow therefore derives the expected state from the same templates and settings used for deployment.
In the project: Deployment and comparison use the same role templates and variables.
A consolidated definition of the intended state.
An exception must mean the same thing during setup and inspection. In Ansible-Hub, these settings belong in the shared group or host configuration.
In the project: The firewall documentation identifies the shared source of the expected state.
Fewer conflicting definitions of the same operational rule.
An executable workflow also needs a clear explanation. Operational guides sit alongside the roles and describe commands, prerequisites and limitations.
In the project: Firewall and SSH documentation describe their workflows and current implementation scope.
Operational knowledge can be read, checked and developed further.
Hand proven routines over to tools.
Collect configuration, compare rules and record the finding: these recurring steps can be described precisely. They form a useful, bounded automation task.
In the project: The firewall check is available as a dedicated Ansible workflow.
A clear scope for reducing repeated manual work.
The checking workflow generates the expected state, reads configuration and active rules, and performs the comparison. One deliberate command handles the individual technical steps.
In the project: The same workflow is documented for local use and a manually triggered CI job.
The check can be repeated without assembling each step again.
A successful overall pipeline does not answer every operational question. Manual checking jobs and their results must be reviewed individually; the finding remains an output in its own right.
In the project: A concise finding and the full execution log are kept separately.
Repeatable technical work with a result that can be assessed.
The tool handles collection and comparison. Which discrepancy calls for a change, and when to intervene, remain deliberate operational decisions.
In the project: Check scope and the change path remain explicit choices; inspection does not repair automatically.
More attention for causes, decisions and the next improvement.
02 / Work
I am Gregor Woitczyk. I develop software, run systems and invent worlds. I want to understand how things connect – and what that understanding makes possible.
Software · Infrastructure · Operations
I develop applications, interfaces and the infrastructure behind them. With Linux, containers and Ansible, I turn recurring operational work into executable steps with results we can check. Development, testing and operations belong together.
AI · Automation · Process control
With Aven, I am developing tools to coordinate people, AI agents and their work. Aven CLI is the local runtime; Penbleth builds on it. Within ALINA, I also work on connecting and running local AI models.
Explore AvenCIRCUMRADIUS · Medical devices
I am co-founder and technical director of CIRCUMRADIUS, the medical device manufacturer formerly known as Die Hobrechts. My work on RADIUS and experience from several audits connect software development with traceable decisions and processes that have to work in everyday practice.
Games · Rules · Interaction
Game development is part of my work, from Motorsportmanager to Die Wimmelburg HD, which I worked on as a co-founder of Die Hobrechts. With Harpin, I also develop a tool of my own that connects written stories to controllable game progression.
Writing · Worldbuilding · Conlanging
With Gelariad, I am developing an imagined world for stories. Through conlanging, I explore sounds, word formation and writing systems. Rules, history and language need to fit together, even when it all starts with an invented idea.
Recognition
03 / Perspective
I work with dependable intermediate results. Like tested climbing anchors, they support the next move. A cause I understand, a working prototype, a reliable process: each makes it possible to move on and adjust the route as I learn, without unnecessary rework.
I want to build things that work without continually demanding our time. That leaves room for what comes next.
04 / Contact
Tell me what you are working on: a system that keeps needing attention, an unclear process or an idea you want to bring to life.
