Running FreeIPA servers in containers: when the approach fits
A platform team weighing Podman or Docker against a host install should start by recognizing that a FreeIPA server is not a stateless web app. The container is only the packaging. Each server runs 389 Directory Server for users, groups, hosts and policies, an MIT Kerberos KDC, a Dogtag certificate authority, and optionally ISC BIND DNS and NTP, while SSSD on every client depends on those services being correct. Those components keep state in the container's data volumes, replicate that state to peers, and hold certificates and keys that must survive restarts and image changes. Moving the install into a container changes how you deploy and rebuild the server. It does not remove replication, certificate renewal or backup from your operating model.
Containers make sense when your organization already runs a container platform with disciplined image building, persistent volume handling and change control, and when you need repeatable test or lab environments that mirror production. They are also useful for short-lived validation of upgrades or migrations before you touch a live topology. A host install is usually the safer default when your team has no container operations experience for stateful services, when the identity servers must sit on dedicated hardware or VMs as the FreeIPA deployment recommendations describe, or when your snapshot, backup and restore procedures are built around host-level tooling. Confirm with your own team which side of that line you are on before choosing a container path for production.
Container options for FreeIPA servers and when each fits
This table compares the decisions that shape a containerized FreeIPA server: container engine, base OS tag, persistent data, networking and role layout. Read each row as a question to settle before the first install, with the fit and the items to confirm against the project documentation and image release notes. The main takeaway is that the base OS tag and persistent data layout are the choices hardest to change later.
| Option | Choose it when | Trade-off | Confirm before you commit |
|---|---|---|---|
| Podman | Your Linux servers are RHEL-family and you want daemonless, rootless-capable operation under systemd | Fewer ready-made examples in some vendor guides than Docker, so more of the unit files and hooks are yours to write | Supported Podman version and systemd integration for your OS release |
| Docker | Your team already runs Docker hosts and has tooling, monitoring and image pipelines built around it | Runs a root daemon, which widens the host attack surface and changes how privilege is reviewed | Engine version, storage driver and whether your security baseline allows the daemon |
| Base OS tag | You need the container userspace to match a supported host or release line you intend to keep | Tags move forward as images are rebuilt, so a rebuild can change libraries and defaults | Which base OS tags the project publishes, their support status and the release notes for each |
| Volume-based persistent data | You want configuration, the 389 Directory Server data and Dogtag files kept outside the container layer | Volumes must be backed up with the server's data, and host paths need correct ownership and SELinux labels | Exact data paths the image expects and how ipa-backup interacts with them |
| Host networking | The server must present its real host name, IP addresses and fixed service ports to clients and replicas | Ports are shared with the host, so conflicts and firewall rules move to the host level | Required ports, reverse DNS behavior and whether the image supports this mode |
| One server role per container | You want clear lifecycle control of a single IdM server with its CA or DNS roles reviewed separately | More containers to monitor and upgrade, and each role still needs its own replica planning | Whether DNS and CA roles are installed in the same container in the image you chose |
| Several roles in one container | A small lab or test environment where one container running every role is acceptable | Upgrades, restores and failures affect all roles together, which is harder to recover in production | Role combinations the project documents as supported for production use |
How to choose the base OS tag for a FreeIPA image
The base OS tag in a freeipa-server image decides which distribution, libraries and crypto defaults end up under FreeIPA, so it matters as much as the FreeIPA version. The cards below cover how the tag ties to a lifecycle, how it meets your patching policy, and what to verify before you pin one.
The tag sets the packages
A container image built on a given OS tag ships that distribution's versions of OpenSSL, 389 Directory Server, Kerberos, Dogtag and SSSD libraries. Two images that both report FreeIPA 4.13.x can differ underneath because their base operating systems differ. Check the package set inside the image, not only the FreeIPA version label, before you assume two tags behave the same.
Lifecycle drives the tag choice
Each distribution publishes its own support window for major releases and point updates. Pick a base tag whose support end date falls after your planned replacement window, not just the date of the FreeIPA release you want. Confirm the lifecycle with the distribution vendor for the exact tag you intend to use, since the image project does not guarantee it.
Match the tag to your patch policy
If your policy requires security patches within a fixed period, check whether the chosen tag receives updates on that cadence and whether the image is rebuilt when the base receives them. An image pinned to an old digest will not pick up fixes on its own. Ask who rebuilds, how often, and how you are notified.
Pin FreeIPA and base together
Record the exact FreeIPA version and base OS tag as a pair in your change records. A FreeIPA 4.13.x release that fixes security issues, such as the 4.13.4 release, only reaches your servers when the image carrying it is deployed. Test the pair in a staging topology before moving production replicas to a new combination.
Confirm the replica OS match
Replicas in one topology should run compatible FreeIPA and OS combinations, and mixing base tags across replicas can create behavior differences in replication and certificate services. Before adding a container replica, confirm that its tag matches or is supported alongside the other servers, and that the image version is one your distribution documents for IdM.
Plan the tag change path
Moving to a new base tag is a rebuild and a redeploy, not a patch. Keep persistent data on volumes outside the image, rehearse the move on a copy of the data, and confirm with the image maintainers how an in-place major tag change is handled. Ask your vendor whether an upgrade path is documented before you commit to a tag that will need replacing.
Setting up a FreeIPA server container step by step
This sequence takes a FreeIPA server from a prepared host to a verified, recorded container. Each step ends with a check so the next step builds on a known state. The result is a server with persistent data, a pinned image reference and confirmed replication.
Prepare the host and name resolution
The team that owns the container host prepares the operating system, time synchronization, firewall rules and DNS before anything starts. Choose the fully qualified name the server will carry, then create forward and reverse records that point at the address the container will bind to. Check the result from the host: a forward lookup of the name returns the address, and a reverse lookup of that address returns the same name. Do not continue until both directions match, because the install writes this name into certificates and Kerberos principals.
Define persistent volumes for data and configuration
The platform engineer creates one host directory for server data and one for configuration, then mounts both into the container at the paths named in the image documentation for the image you plan to use. Apply the SELinux relabeling option on the mounts if the host enforces SELinux. Data must survive container replacement, because the directory database, Kerberos keys and certificate authority data live in these paths. Confirm the directories are owned and writable by the container user, then start and remove a throwaway container to check that files persist.
Pull a tagged image from your registry
The team mirrors the freeipa-server image into a registry it operates and chooses a tag that matches the base operating system it has standardized on. Avoid floating tags such as latest, because a rebuild can change packages under a running server without a change record. Pull the tagged image on a staging host and confirm it starts with the mounts from the previous step. Check that the base operating system matches a platform your organization supports, and record the chosen tag in the change ticket.
Run the server install with hostname and realm
The engineer starts the container with the persistent mounts and runs the server installation inside it, using the chosen hostname and Kerberos realm and the options from the install documentation for the release in use. Agree the realm with the security team first, because changing it after install is not a routine task. Supply the directory manager and admin passwords from a secret store, not from shell history or a plain-text file. Check the install output for a success message and confirm the container reaches the expected running state.
Verify services and replication
Inside the container, confirm that the directory, Kerberos, certificate authority and DNS services (where installed) report as running. From a separate enrolled client, log in with an administrator account to prove that Kerberos works end to end. If this server joins an existing topology, list its replication agreements and confirm each one is healthy. Compare the agreement count with the FreeIPA deployment recommendations, which advise no more than four replication agreements per replica, and confirm which server handles certificate renewal.
Record the image digest and configuration
Record the digest of the image that ran, not only its tag, in configuration management and the change record. Read the digest from the local image store on the host with the podman image inspect command and its digest format option, then store it alongside the volume paths, hostname and realm. Check that the digest matches the value shown in your registry for the tag you pulled. This record lets you rebuild the same image later and gives you a fixed reference point for the next rebuild or upgrade decision.
Keeping FreeIPA data safe across container rebuilds
The container image is disposable, but the FreeIPA state inside it is not. Directory data managed by 389 Directory Server, the Dogtag certificate authority's keys and certificates, and the Kerberos keys in the KDC all live under the server's data directory. Those paths must sit on a persistent volume that is mounted into the container and survives image upgrades, container removal and host rebuilds. Before the first install, confirm with the image documentation which paths the project expects as volumes, whether the host directory needs specific SELinux labels for Podman, and which ownership the container's internal user requires. Test a rebuild on a throwaway host with a copy of the volume before you trust the setup for production.
Mirror the freeipa-server images you use into an internal registry you control, and pin each deployment to a specific tag or, better, an image digest. A floating tag can change under you during a routine restart or a re-pull, and a server that comes back on a newer image than its replicas can create upgrade questions you did not plan for. Record the digest alongside the volume state, and change it only through a deliberate, tested step that is part of your upgrade plan. Confirm with the project which image tags are current and supported for your platform before you choose one, because the supported base operating system tags are not something this section can state.
A surviving volume is not a recovery plan. If a volume is restored from a storage snapshot, a restored copy can be out of step with the rest of the topology, and the FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Run ipa-backup on a schedule from inside the container, copy the archives off the host, and rehearse ipa-restore against them. Ask the project's current guidance on restoring into containers and whether volume snapshots alone are acceptable for your topology. Our backup and restore documentation is the natural next read for the restore steps.
Rebuild cadence and patching for containerized FreeIPA
A containerized FreeIPA server is only as current as the image it runs, so rebuild timing is a standing operational decision. The cards below cover the choice between rebuilding on every base OS update and rebuilding only for FreeIPA releases, how to test a new image against a staging topology, what happens to existing volumes, and what to confirm before each rebuild.
Rebuild on base OS updates
Rebuilding whenever the base OS image changes keeps libraries, crypto packages and the container userland current, even when FreeIPA itself has not changed. The cost is frequency: each rebuild is a new artifact that needs the same validation as a FreeIPA upgrade. Ask who owns the rebuild trigger, how often the base tag is refreshed, and whether a rebuild can be rolled back to the previous image digest without touching data volumes.
Rebuild for FreeIPA security releases
The alternative is to rebuild only when the FreeIPA project ships a release that matters for your deployment. Release 4.13.4, a stabilization release dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials. Security-driven rebuilds are fewer and easier to schedule, but they depend on someone reading release notes promptly and treating a security fix as an urgent change.
Test in a staging topology
Test each rebuilt image against a copy of your real topology, not a single container. Replication, certificate renewal on the first server, DNS and client enrollment behave differently across several replicas. Confirm that the staging environment uses production-like hostnames, DNS, time sources and replication agreements, and that you run ipa-healthcheck and a client login test after the rebuild before any production replica is touched.
Upgrade path for existing volumes
Persistent data lives in volumes, not in the image, so a new image starts from the same directory data. Confirm with the FreeIPA release notes whether the new version requires a schema or data upgrade, and whether the image's entrypoint performs it automatically. Take a full backup before the first start, and keep the old image tag available so you can stop the new container and start the old one if the upgrade fails.
Replica ordering during rollout
Roll out one replica at a time and leave the first server, which handles certificate renewal and CRL publication by default, for last or on a planned window. Restoring an outdated backup into an active replica topology can break replication, so a rollback should never be done by restoring old data onto a live replica. Record which replica runs which image digest so incidents can be traced to a specific build.
Release notes to check before each rebuild
Before each rebuild, read the FreeIPA release notes for the target version and the base OS vendor's notes for the chosen tag. Confirm changes to default settings, deprecated features, required manual steps, supported client distributions and any CVE fixes. Note that the FreeIPA project is community-run, so ask your image maintainer or internal owner to confirm which upstream release and base tag each image was built from.
Questions buyers ask about FreeIPA containers
Do containers make FreeIPA easier to run?
Containers simplify the package install and make a server rebuild a repeatable step, but they do not remove the design work. Identity naming, replica placement, DNS, certificates and backups still need decisions before anything runs. The directory, Kerberos keys and CA material live in persistent data that must sit on storage you can back up and restore. Containers also do not change the replication rules. The FreeIPA deployment recommendations advise dedicated servers without other applications, so a shared container host needs its own review. Confirm with the project's image documentation which base OS tags and FreeIPA versions the images support before you standardize on them.
What drives the cost of a FreeIPA container implementation?
Most of the cost is the work of designing and proving the deployment, not the container runtime itself. The main drivers are the number of replicas, the number of sites, how many clients need enrollment, whether existing users or policies migrate in, and whether you add an Active Directory trust, multi-factor authentication or a certificate design beyond the defaults. Backup and restore testing adds effort because it has to be proven, not assumed. The FreeIPA deployment recommendations suggest two to three replicas in each datacenter, so topology size is a direct cost lever. Ask for a quote that separates one-time work (design, build, migration, testing) from recurring work (rebuilds, upgrades, monitoring, support).
How long does a FreeIPA container deployment take?
Duration depends on the same drivers as cost: topology size, number of sites, migration volume, integrations and how quickly your teams approve decisions and change windows. A single test server with a small client set moves far faster than a multi-site production topology with a trust and a certificate design. DeployOpen's engagements are fixed-scope, so the timeline is written into the agreed scope before work starts, along with deliverables and the acceptance evidence for each phase. Ask any provider to show the milestones, the decisions that must be made by your team, the test restores included, and the dependencies on your network, DNS and platform teams. If a timeline is not tied to those items, treat it as an estimate that will move.
What does the work need from our team?
Your team supplies the decisions and access that only your organization can make. An identity owner needs to settle the realm and DNS domain naming, and the network team must confirm ports, DNS placement and time synchronization. The platform team provides the container hosts, persistent storage and registry access. Security and compliance staff approve policy choices such as password rules, certificate handling and multi-factor methods. Someone must also own change windows and sign off test results. Before work starts, confirm who can grant access to the hosts, who approves production changes, and who keeps the runbooks current after handover.
Can our own team run FreeIPA in containers without a partner?
A team with solid Linux, LDAP, Kerberos and DNS skills can build and run FreeIPA in containers without outside help. The hard part is rarely the first install. It is recovery when something fails. The FreeIPA backup documentation warns that the first server handles certificate renewal and CRL publication by default, and that restoring an outdated backup into an active replica topology can break replication. Before you go alone, write runbooks for replica failure, CA renewal server loss and restore, and prove them in a non-production environment. A fixed-scope partner can cover the design, the build and the recovery testing, leaving your team with documented procedures it has rehearsed.
How do rebuilds and upgrades change the workload for containerized FreeIPA?
Each new image means a replacement cycle, so the work shifts from patching in place to planned rebuilds and rejoin checks. Security releases matter here. The FreeIPA 4.13.4 release notes describe fixes for two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, so a rebuild schedule must allow prompt action. Upgrade order across replicas, data volume reuse, and verification of replication and certificate state after each rebuild all need a written procedure. Confirm whether a rebuilt container reattaches the existing data volume cleanly, and ask how the provider tests a rolling change before it reaches production.
Is a container the right choice for every FreeIPA server?
Containers fit well where your organization already runs a container platform, wants repeatable server builds, or needs disposable lab and test environments. They are a weaker fit where the host must stay dedicated to identity services, where your operations team lacks container storage and networking experience, or where a server role depends on host-level configuration that is hard to manage in a runtime layer. Standardizing every role in containers adds a layer you must patch, monitor and back up. Choose per environment, and document which roles run in containers and why, so future rebuilds follow the same rules.
What should we ask a partner before signing a containers scope?
Ask for specifics that show how the work will be run after handover. Request the base OS tag and image source the design uses, the location of persistent volumes, and the backup method for them. Ask how a replica is rebuilt and rejoined, who owns CA renewal and recovery, and what restore evidence will be delivered. Confirm which items are one-time deliverables and which belong in an ongoing retainer, since upgrades, security releases and continuous testing usually recur. Finally, ask which decisions remain with your team, so the written scope matches your ownership model and nothing important is left implied.
How DeployOpen scopes and delivers FreeIPA container work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so FreeIPA containers run on hosts and storage you control. Engagements start with a written scope that sets out which images, registries, persistent volumes and rebuild steps are included before any work begins.
How we scope
- Confirm whether containers suit your topology, including replica count per site and which server roles run on each host.
- Record the base OS tag, container runtime and host distribution in the written scope, with the reasons for each choice.
- Agree which persistent data paths, backup targets and registry sources the engagement covers, and which stay with your team.
How we build
- Deploy FreeIPA server containers with persistent storage for configuration, data and certificate material mapped to volumes you own.
- Test replication, DNS, certificate issuance and client enrollment against the running containers before they reach production.
- Set up a repeatable rebuild procedure so image updates follow a documented cadence and can be rolled back on your hosts.
How we hand over
- Deliver runbooks covering container start order, volume locations, restore steps and the checks to run after any rebuild.
- Document the image provenance, tag choices and registry access model so your team can audit each running version.
- Walk your platform and security staff through the operating procedures and record open items against the agreed scope.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Retainers can cover image rebuilds, FreeIPA release upgrades and re-verification of replication after host changes.
- Ask any provider to confirm how image updates, security releases and volume backups are handled before signing.
