Support for Debian 11 ended on 31 August 2026, and for CentOS 7 on 30 June 2024 (As of 2026-10). We will upgrade your server, or plan and carry out the move to Debian. We also work with Proxmox VE 8 and with physical servers that we move to Proxmox.
Ansible for Linux servers: configuration as code in a repository
We describe the configuration of your Linux servers with Ansible, in a Git or SVN repository with separate inventories for production and test. Every detail of the configuration is then documented, and every server can be rebuilt within minutes, without anyone having to remember what was once changed by hand.
- Ansible with separate inventories for production and test
- Full stack and DevOps since 2012
- The repository usually stays with you
Where we use Ansible
Ansible describes the configuration of Linux servers in text files: packages, services, users and SSH keys, configuration files and firewall rules. The files live in a Git or SVN repository. Ansible connects to the servers over SSH and brings them into the described state, with no agent of its own running on them.
We use Ansible for servers that have so far been maintained by hand, and wherever several servers should be set up the same way. Our engineers work with Ansible and separate inventories for production and test. Day-to-day server operations are covered under Linux & DevOps. With Ansible we also set up hosts for Docker and virtual machines on Proxmox consistently, for example after a move from hosting to containers.
When servers have been maintained by hand for years
Ansible pays off above all in these situations:
- The servers were set up by hand, and their configuration exists only on the servers themselves.
- Nobody knows exactly what was changed last, or why.
- Test and production differ, and errors only show up in production.
- A new administrator needs a long time to get to know the servers.
Changes made by hand are rarely written down. After a few months nobody knows what was changed on which server, and the knowledge of the configuration fades. With Ansible, every change goes through the repository and is recorded there as a commit with date, author and description, and every detail of the configuration is documented and reproducible. For a single server that rarely changes, the effort is often not worth it. Good documentation and a runbook are then enough.
Typical tasks with Ansible
- An inventory of the existing servers: packages, services, configuration files, users, cron jobs and firewall rules.
- A Git or SVN repository with roles for recurring building blocks such as web server, PHP or Lucee, database, mail delivery, users and SSH access.
- Separate inventories for production and test. Differences such as server names and addresses are kept as variables in each inventory.
- Passwords and keys stored encrypted in the repository, never in plain text.
- Rolling out updates and security settings such as SSH hardening and firewall rules to many servers, test servers first.
- Preparing servers for Docker and setting up virtual machines on Proxmox consistently.
- Documentation in the repository and a runbook for your team.
A server that can be rebuilt from the repository
An Ansible run changes only what differs from the described state, and a second run straight afterwards reports no further changes. If a described setting was changed by hand, the next run shows the difference and restores the described state. We try new roles and changes on the test servers first; production follows in a time window agreed with you.
If a server fails, or moves to new hardware or into a virtual machine, its configuration is rebuilt from the repository. Databases and uploaded files are not part of the description; they come from the backup. That is why backups with a restore test belong with it. The repository usually stays with you, so a new administrator or another provider can look up there how the servers are set up.
How we introduce Ansible on existing servers
-
Inventory
We record what is set up on the servers and compare test and production. You receive the list of differences in writing.
-
Repository and roles
We create the repository, usually on your side, and describe the servers in roles and separate inventories for production and test.
-
Matching on test
We build a test server from the description and compare it with production until every difference is explained.
-
First run on production
We agree the plan, the timing and the way back with you in advance. Before the run we check the backup; afterwards we check services and application.
-
Documentation and handover
The repository explains how to start a run, which inventories exist and where the encrypted passwords are kept. A runbook for your team comes with it.
Related starting points with servers
-
-
We move your Lucee, ColdFusion or PHP application from classic hosting into containers without rewriting it. That lets you rebuild, update and relocate the environment. Security updates for PHP 8.2 end on 31 December 2026 (As of 2026-10).
-
Your system runs, but nobody knows it in detail. We record application, database, server and email, assess the risks, recommend the next step in writing and, if you wish, take over operations.
The first step: a server check with a written result
Server check
For companies with Linux servers that nobody knows well any more: before an upgrade, after the administrator has left or when a client asks about backups.
- Version and support status of the operating system and services
- Hardening: SSH access, firewall, open services and TLS certificates
- Updates: what is missing and how they have been applied so far
- Backups: what is backed up and whether a restore test is documented
- Monitoring and logs: what is monitored and what is missing
- List of findings in order of priority
At this stage we change nothing on the server. The check does not cover the application or its code. That is what the legacy review is for. We agree the scope and price in the intro call and confirm them in writing before we start. If you wish, you then receive a quote for ongoing support.
What the result contains
A written list of findings in order of priority, with recommendations on hardening, updates, backups and monitoring, plus an upgrade plan with maintenance windows. Both are yours.
What clients often ask before we start
What if we are missing access credentials?
This can usually be solved. We start with what you still have to hand. That is the contract and customer account with the hosting provider, access to the domain and, where available, the repository and backups. Server access can often be reset through the hosting provider if you act as the contracting party. We only gain access to a system with your explicit consent.
Do you work with Jira, Git and SVN?
Yes, with Git and with SVN. We manage tasks in Jira or in the tool you already use. The code lives in your own repository and therefore stays in your hands.
What happens if someone at your company is unavailable?
We arrange a substitute on request. We also write the documentation on request, and the repository is normally held on your side, so the code stays in your hands. How we work together is described on the page How we work.
Do you have experience with Linux and Windows Server?
Linux is our main platform: Debian and Ubuntu, web servers, database clusters and virtualisation with KVM and Proxmox. We have run Windows Server with IIS in production since 2015. We recommend moving to Linux unless you prefer to stay with Windows.
When can you start?
You will receive a first reply within one working day. When we begin work depends on our current workload and on the scope. We give you a binding answer in the intro call. If it is urgent, the 48-hour emergency assessment starts as soon as we have access to the system.
What is your hourly rate?
It depends on scope, engagement model and urgency. Describe your situation briefly and, after a conversation, we will send you an offer. You do not need a budget for that. We quote fixed prices for the entry products.
Describe your servers to us in three sentences
Tell us how many servers you run and with which operating system, where they are located (with you or at a hosting provider) and whether a test environment already exists.