What FreeIPA costs to run
FreeIPA has no license fee and no paid edition of its own. The project is licensed under GPL-3.0-or-later and is community-developed, so the cost of running it sits in three places: the servers that host it, the people who operate it, and any support contract you choose to buy. The infrastructure line depends mostly on replica count. FreeIPA's deployment recommendations advise two to three replicas in each datacenter, on dedicated servers, so a multi-site estate multiplies hosts, backups and monitoring.
Teams usually open a total-cost review when something changes. Common triggers are a new Linux estate that needs central identity, a request to trust Active Directory users, the retirement of a commercial identity product, or an upcoming OS lifecycle change that forces server rebuilds. Each trigger adds different work. An AD trust adds trust components and ID mapping decisions, and an OS change means new replicas and a tested upgrade path. Record which trigger applies before you compare estimates.
Teams that already run Linux, LDAP and Kerberos at scale usually keep FreeIPA in-house after go-live. Teams without that depth, or with a small operations group, often use a partner for the first build and then decide whether to keep ongoing support. Ask every quote to separate one-time build effort from recurring work: monitoring, certificate renewal checks, replica upgrades, restore tests and on-call time.
Some Linux distributions and vendors package FreeIPA or sell support subscriptions under their own terms and editions. Treat those as a separate question from the upstream project. Confirm with the specific vendor what is included, what support terms apply, and how the offering fits your OS lifecycle plan before you assume any cost.
What a cost of ownership assessment includes
A cost of ownership assessment turns FreeIPA's zero license fee into a written picture of the people, servers and recurring work needed to run it. Each item below is a deliverable or input you can check before committing to an operating model.
Inventory of servers, sites and integrations
The assessment starts with a list of every IdM server, datacenter, client population and integration that depends on the realm. It records which Linux hosts use SSSD, which services rely on Kerberos or LDAP, and which applications, VPNs or network devices authenticate against FreeIPA. This inventory sets the scope for every later cost line, so check it against your actual host and application counts rather than a rough estimate.
Replica count per datacenter
Using the project's deployment recommendations, the assessment models how many replicas each datacenter needs, usually at least two or three, with no more than four replication agreements per replica. It also decides which replicas run the CA or DNS roles. Each extra replica adds a server to patch, monitor and back up, so the count directly drives recurring operating effort.
AD trust, OTP, RADIUS and migration needs
The assessment maps whether you need a cross-forest trust with Active Directory, which requires a DNS domain that does not overlap with the AD forest, and whether users need OTP tokens or a RADIUS proxy for existing two-factor systems. It also identifies identities to move from OpenLDAP, NIS or another FreeIPA domain. Each of these adds configuration, testing and support work that a single-realm estimate would miss.
Recurring work calendar
The assessment lays out a calendar for recurring tasks: checking certificate renewal, running and testing backups, applying security releases such as stabilization updates, and tracking operating system lifecycle dates for every IdM server. Ask who performs each task and how often. These tasks repeat for the life of the realm, so they form the largest share of ongoing cost.
One-time and recurring cost model
The assessment ends with a written cost model that separates one-time items, such as design, migration, trust setup and initial hardening, from recurring items, such as staff time, server hosting, monitoring, upgrades and support. Ask for each line to name the party paid for the work. A model in this form lets you compare an internal team against a partner on the same basis.
Deliverables you receive
At the end you receive the inventory, the replica and site model, the trust, OTP, RADIUS and migration map, the recurring work calendar and the cost model, each as a written document. Confirm the format, the review meeting and who owns each document before the assessment starts, so the figures can be reused in budget and staffing decisions.
What drives FreeIPA cost
The table lists the factors that move FreeIPA run cost and effort, why each one changes the bill, and how to keep it contained.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Datacenters and servers | Each datacenter needs two to three replicas on dedicated servers, so every added site adds hosts to patch, monitor and back up. | Limit sites that need local replicas, and confirm with your architect which sites truly need a CA or DNS replica. |
| Enrolled Linux hosts and clients | Enrollment volume raises SSSD configuration work, policy review and support tickets, though the servers themselves change little. | Automate enrollment with your provisioning tooling and group hosts into host groups so policy is set once. |
| AD trust scope and DNS domain separation | A cross-forest trust needs Samba-based components, ID mapping work and a non-overlapping IPA DNS domain, which means more design and testing time. | Confirm the AD forests in scope before design starts and avoid trusting forests that no Linux host needs. |
| Certificate volume and profile needs | Each custom certificate profile, issuance workflow or renewal check adds design, testing and operational review, and the first server handles renewal and CRL publication by default. | Start with the default profiles, document any extra profiles, and schedule renewal checks as routine work. |
| OTP and RADIUS use | Two-factor login needs token enrollment support, helpdesk procedures and, when proxying to an existing RADIUS server, integration testing against that server. | Confirm which users and hosts need OTP, and reuse an existing RADIUS service only if its owners will support it. |
| Migration sources | Moving identities from OpenLDAP, NIS or another FreeIPA domain adds mapping, password handling and manual sudo and HBAC rule work, depending on the source. | Inventory source directories and rules first, and migrate only the accounts and policies still in use. |
| Backup and restore testing | Backups are cheap to schedule but restore tests need staff time, lab capacity and careful handling of outdated backups in a live replica topology. | Run restore tests on a scheduled cadence in a lab, and ask the provider to include them in the written scope. |
| Monitoring depth | Dashboards and alerts for replication, certificate expiry, DNS and Kerberos health add setup work and ongoing alert tuning. | Start with replication, certificate expiry and DNS checks, then extend monitoring as operations need it. |
| Staff skill coverage | Running FreeIPA well needs Kerberos, LDAP, DNS and PKI knowledge, and a thin team increases reliance on outside help or slower incident response. | Cross-train two or more staff members and ask any partner to document runbooks and handover steps. |
How a cost review runs
A fixed-scope cost review moves from current identity sources to a written cost model that your owners have checked and can maintain after handover.
Inventory identity sources and hosts
The review team, with your identity and Linux platform owners, lists current directories, user and group sources, Linux and UNIX hosts, DNS and NTP services, sites and any Active Directory forests that FreeIPA might trust. The output is a source inventory with host counts per datacenter, what each host runs, and which systems touch authentication today. The step closes when your owners confirm the inventory matches their records.
Design topology and server count
Using the inventory, the review sketches a replica layout per datacenter, applying the project's deployment guidance of two to three replicas per datacenter and the limit on replication agreements per replica, and decides where the CA and DNS roles sit. The output is a topology diagram with a server count per site and the reasons for each placement. Ask the reviewer to state which assumptions drive the count, such as dedicated hosts or whether DNS is used.
Build the one-time and recurring cost model
The review separates one-time work (design, build, migration of users and rules, AD trust setup, testing and cutover) from recurring work (patching and security releases, certificate checks, backup verification, monitoring, and staff time). The output is a model with each line tagged to who pays for it: your staff, DeployOpen under the written scope, or a third party. Ask the reviewer to show which lines scale with server count and which stay flat.
Review the model with your owners
The draft model goes to your identity, security, platform and finance owners for a working session. They challenge assumptions about staffing, change windows, on-call coverage, the OS lifecycle of the servers and any licensing or hosting costs you already carry. The output is a list of agreed changes and open questions, each with a named owner. The step closes when every open question has an owner and a date set in the written scope.
Hand over the model and assumptions
The review team delivers the final model, a written assumptions register and the source inventory to your team, and walks through how to update each line when server count, sites or support arrangements change. The output is a signed-off handover pack. Confirm in the written scope exactly which files, formats and walkthroughs are included before work starts.
Recurring costs after go-live
This table lists the costs that continue after a FreeIPA deployment goes live, marks whether each line recurs, and flags the lines to confirm with a distribution or vendor.
| Cost line | One-time or recurring | What drives it | Confirm before quoting |
|---|---|---|---|
| Servers and hosting per site | Recurring | Two to three replicas per datacenter, dedicated hosts, plus any DNS or PKI replicas you run | Your hosting or cloud rates. FreeIPA itself carries no license fee. |
| Backup storage and restore tests | Recurring, with one-time setup | Backup frequency, retention period, storage location, and time to run restore tests on a separate host | Storage terms and any paid backup tooling your team chooses |
| Certificate operations | Recurring | Renewal checks on the first server, CRL publication, and certificate profile changes as applications change | Which replica holds the renewal and CRL roles in your topology |
| Security release application | Recurring | Stabilization release 4.13.4, dated July 9, 2026, fixed two CVEs, so each replica needs patching and testing | Whether your distribution packages FreeIPA and on what update channel |
| OS lifecycle replacement of replicas | Recurring | Replacing replicas one at a time as operating system support ends, without breaking replication | Your distribution's support dates and any extended support subscription |
| Monitoring tooling and on-call | Recurring | Alerts on replication health, certificate expiry, and service availability, plus out-of-hours coverage | Whether existing monitoring licenses already cover these checks |
| Internal staff skills | Recurring | Time to keep administrators current on Kerberos, LDAP replication, and certificate operations | Training fees and whether your team can cover this work internally |
| Optional support retainers | Recurring, optional | Ongoing upgrades, monitoring review, and testing, scoped in writing before work starts | DeployOpen quotes from written scope. Distribution support subscriptions are billed separately. |
Where FreeIPA cost estimates go wrong
Most FreeIPA budgets miss the same few items. Each card names one gap in the cost model and the check that closes it before the estimate is approved.
Replica count across sites
The deployment recommendations advise at least two to three replicas in each datacenter, with no more than four replication agreements per replica. Estimates that count one server per site understate server, OS and operations effort. Ask the partner to model replicas per datacenter, the agreement topology between them, and who patches each node.
Overlapping DNS domains before trust
The IPA domain must not overlap with any DNS domain in the Active Directory forest before a cross-forest trust can be set up. If the naming decision is made late, realm renaming, client reconfiguration and DNS changes become rework. Put the domain decision and an AD namespace check in the design phase, and cost it as a separate line.
Backups treated as tested
ipa-backup produces files, but a backup that has never been restored is an assumption, not a recovery capability. Budget time for restore rehearsals on a separate environment, including certificate and DNS data. Ask who runs the test, how often it repeats, and where the evidence is stored.
Outdated backup in a live topology
The backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Recovery steps that were never written down turn a single failure into a multi-hour outage with staff time billed at incident rates. Cost the runbook, the replica rebuild steps and the escalation path before go-live.
Unmonitored first server renewal role
By default the first server handles certificate renewal and CRL publication. If nobody watches that role, certificate expiry can surprise the team months after go-live. Add monitoring for certificate expiry and CRL status to the operations scope, and confirm who owns the response when an alert fires.
Deferred security releases
FreeIPA 4.13.4 fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials. Holding patches to save effort leaves identity infrastructure exposed. Model a recurring patch window, a staging replica for testing, and the staff time each cycle requires, rather than a one-time upgrade line.
Assuming no staff time
The software carries no license fee, but the project is community-supported with no paid edition, so support, upgrades, monitoring and incident response are paid as labor or retainers. Estimates that show zero software cost but no people cost mislead budget owners. List internal roles, hours per month and any partner retainer as recurring lines.
What you need to provide
A FreeIPA cost model is only as good as the inventory behind it, so the first thing to send is a count of Linux hosts by site and datacenter, with each host's role, OS release and whether it is a candidate for an IdM replica, a client, or both. Add the network links between sites and any air-gapped or segmented zones. Replica count per datacenter, replication agreement fan-out and the number of DNS and CA roles all follow from this list, so an approximate spreadsheet is more useful than a precise one delivered late.
Next, describe every current identity source and its size: OpenLDAP or other LDAP directories, NIS maps, local account files, and any existing Kerberos realm. For each one, give the approximate number of users, groups, hosts and sudo or access rules, and state whether password hashes can be migrated. Also state the planned Active Directory trust requirements: which forests and domains, whether the trust is one-way or two-way, and which Windows users must sign in to Linux hosts. These answers decide whether migration and trust work appear in the quote as separate line items.
Provide the certificate use cases the platform must serve: internal web services, host and service certificates, VPN or wireless certificates, and any external certificate authority you must chain to. Name the owner of the root or intermediate CA decision. Also send your backup and recovery targets (recovery point and recovery time objectives, retention period, offsite copy requirements) and the monitoring tools already in use, so the model can account for integration effort. Confirm your OS lifecycle calendar for every host, since in-place upgrades and replica replacements recur over the life of the platform.
Name three accountable owners: one for identity, one for security, and one for operations. Ask each to sign off on the assumptions in the model, including host counts, site count, trust scope and support hours. Sign-off should come from the budget holder as well, because the recurring staffing line depends on it. After handover, the model is usually maintained by the operations owner, with the identity owner approving changes to replica topology or trust scope. Confirm this split before work starts so the document does not go stale.
Frequently asked questions
Does FreeIPA itself carry a license fee for production use?
No license fee applies to the FreeIPA software itself. FreeIPA is licensed under GPL-3.0-or-later and is a community project with no paid edition of its own. Costs come from the parts around the software: the Linux servers and their operating system subscriptions if you buy them, the time your team or a partner spends on design, build and operations, and any support contract you choose to buy from a distributor. Confirm with your distribution whether its packaging or support terms carry a charge.
What drives the total cost of running FreeIPA?
Most of the bill is people time and infrastructure. The main drivers are the number of sites and replicas, how many hosts and clients enroll, whether you add an Active Directory trust, how often certificate and CA checks run, how many upgrades you schedule each year, and how monitoring and backups are staffed. Each driver produces one-time work (design, initial build, enrollment) or recurring work (patching, certificate checks, backup tests, on-call). Ask any partner to split its quote into those two groups so you can compare it with your internal estimate.
How does the number of servers across datacenters change the cost?
Each datacenter usually adds replicas, and replicas add build, monitoring and patching work. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter and no more than four replication agreements per replica, so topology design matters as sites grow. Each site that runs the CA or DNS needs at least one replica with those services, and servers should be dedicated to FreeIPA without other applications. Ask for the replica count, site list and replication layout in the written scope, because they drive hardware, operating system licensing and recurring operations.
Does an Active Directory trust add significant effort to a FreeIPA deployment?
It adds a distinct workstream, and the earliest decision is DNS. FreeIPA can set up a cross-forest trust with Active Directory through Samba components, but the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. That naming choice must be settled before the realm is built. Effort then covers ID mapping, ID views and testing of AD users on Linux hosts under your access policy. Confirm with your AD team who owns the trust, and ask a partner to list it as a separate phase with its own acceptance tests.
How often does recurring FreeIPA maintenance happen?
Recurring work follows your patch policy and the release cycle you adopt, so your change calendar sets the cadence. Typical recurring items include applying stabilization and security releases, upgrading replicas one at a time, checking certificate renewal, testing backup and restore, and tracking operating system lifecycle dates. Security releases need a fast path: FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws. Ask your partner to state the expected cadence for each item in the written scope.
Can our own team run FreeIPA without an outside partner?
Yes, a team can run FreeIPA internally if it has the skills and time for the work. Operators need working knowledge of Kerberos, LDAP replication, DNS, certificate authority operations and SSSD on clients. The first server handles certificate renewal and CRL publication by default, so backup and restore discipline matters, and restoring an outdated backup into an active replica topology can break replication. Also confirm you have on-call coverage for identity outages. A partner's written scope should name the phases, deliverables, handover documentation, acceptance tests and post-go-live support.
How DeployOpen scopes and supports FreeIPA
DeployOpen plans, builds, documents and supports FreeIPA inside your own datacenters and cloud accounts, so the cost you carry is the platform, the infrastructure and the people time, not a license fee. The sections below show what a written scope covers for cost of ownership decisions and how the engagement is handed over.
How we scope
- Engagements are fixed-scope, so the written scope states the server count, datacenters, replicas and clients covered.
- The scope names which optional parts are in or out, such as AD trusts, OTP, DNS and NTP, certificate profiles and backups.
- Ask for the scope to list who runs upgrades, monitoring and certificate checks after go-live, since those recur.
How we build
- We size the replica topology per datacenter against the vendor deployment recommendations and document each assumption.
- We build the CA, DNS and backup design, then test ipa-backup and ipa-restore on a non-production copy before go-live.
- Each cost driver we identify, such as AD trust setup or migration from OpenLDAP, is tested and recorded as its own work item.
How we hand over
- You receive the documented topology, runbooks for replica and certificate operations, and the backup and restore procedure.
- Handover includes a list of recurring tasks with owners, such as stabilization upgrades, OS lifecycle work and CRL checks.
- We record which items your team must staff internally so you can compare the true people cost against a quote.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope build.
- Retainer scope should state which FreeIPA 4.x releases, including security fixes such as those in 4.13.4, are applied and how fast.
- Ask any quote to separate one-time build effort from recurring support, so the total cost of ownership is visible over time.
