How many FreeIPA servers does your deployment need?
Your server count follows from your sites, the server roles you need at each site and the replication layout that connects them. Memory follows from the number of users and clients and from the roles each server carries. Treat both as outputs of a written topology, and confirm the limits and memory figures against the FreeIPA sizing guidance for the release you plan to run before you order hardware. FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD on clients, with optional ISC BIND DNS and NTP, so each server you add carries a directory, a KDC and, if you enable them, a certificate authority and DNS service.
Start by listing your sites and the roles each site must serve locally: authentication, certificate issuance, DNS and any trust with Active Directory. The FreeIPA deployment recommendations advise at least two to three replicas in each datacenter and no more than four replication agreements per replica, and they ask for dedicated servers without other applications. Those guidelines set a floor for each site. Check the server limit in the sizing guidance for your release, since it caps how far a single topology can grow, and check how many clients each server is expected to serve. Write the expected user count, client count and per-site login rate next to each site so procurement uses the same numbers as the design.
Memory is the figure procurement is most likely to get wrong. Ask the sizing guidance for the RAM and swap it recommends for your user count, first at roughly 10,000 users and then at 100,000 users, and ask whether those figures change when a server also runs the CA or DNS. Ask your vendor or integrator to state the memory assumptions behind each quote, and keep a plan for growth, because adding servers later means new hardware, new replication agreements and a new DNS check. Validate the design in a lab with representative load before you commit the production order.
Which sizing inputs change the server count and memory
This table compares the inputs that move the number of FreeIPA servers and the memory each one needs, and what pushes each input up or down. Read each row as a question to answer for your own sites before fixing a server count, then confirm memory and client figures with your vendor and a test environment.
| Input | What drives it up or down | When each option fits |
|---|---|---|
| Replicas per data center | Number of users, client load and how many sites must keep working if one site is lost. Recommendations advise at least two to three replicas in each datacenter. | Two replicas for a small site with a second site nearby, three where losing one server would leave authentication fragile or where client load is high. |
| Replication agreements per replica | Agreements grow with the number of servers in the topology. Recommendations advise no more than four agreements per replica, so larger layouts need deliberate topology design. | Keep each replica within four agreements. Add servers to a site before adding long chains of cross-site links that would exceed that limit. |
| CA and DNS placement | Certificate authority and integrated DNS roles add load and operational duties. Recommendations advise at least one replica per datacenter running PKI or DNS where those services are used. | Put PKI or DNS on at least one replica in each data center if you use them there. Skip DNS roles on sites that rely on external resolvers, and confirm the role split with your certificate and DNS plans. |
| Backup host | Backups need disk space, a copy kept off the server and time for full or data-only runs. Backup documentation notes that restoring an outdated backup into an active topology can break replication. | Use a dedicated backup target or a separate server with enough storage for your retention policy. Confirm the required disk size with your vendor and test restores before go-live. |
| Dedicated versus shared hosts | Shared hosts compete for memory and CPU with other applications, which makes memory sizing unpredictable. Recommendations advise dedicated servers without other applications. | Dedicated virtual machines fit most production deployments. Shared hosts only suit labs or small pilots where you accept the risk of contention. |
| Users and clients per site | Authentication volume, Kerberos ticket traffic and the number of enrolled hosts. Each site's load determines whether a single replica can carry it. | Count users and enrolled machines per site and plan for growth. Ask for tested memory and client figures for your user count, since this page does not supply them. |
| Memory and swap | Memory needs rise with directory size and client load, and swap affects behavior when memory runs short. The supplied facts do not give figures for 10,000 or 100,000 users. | Size memory and swap from a documented guide for your FreeIPA version and a load test on representative hardware. Ask the vendor or your partner to confirm both values in writing. |
How site layout sets the FreeIPA replica count
The replica count starts from the site plan, not from the user count. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter, and no more than four replication agreements per replica. Count your sites first, then count the replicas each site needs, and only then size the hardware for each server. A site with a single replica has no local failover, and a topology where each replica already holds four agreements has little room to add links later without redesigning the mesh.
The more important constraint is connectivity. Replication agreements must form a topology in which every server can reach every other server through the agreements, even when one site is unavailable. If a site's replicas are linked only to each other and to nothing else, losing the site's uplink can isolate the clients that depend on it. Check that each site has agreements into at least two other sites, and confirm that the chosen agreements keep the remaining servers connected after you remove any one site on paper. Clients that cannot reach an IPA server cannot authenticate, so this check matters more than the raw server count.
More replicas buy availability, but each one adds replication traffic, another database to back up and patch, another certificate and DNS role to keep consistent, and more to watch in health checks. Treat the per-site number as a design choice to confirm before ordering hardware. Review the layout against the multi-datacenter topology guidance, confirm which servers will carry the CA, DNS and trust roles, and agree the final count with your platform team. Ordering servers before that review often leaves you with the wrong number of machines in the wrong sites.
Which FreeIPA server roles add load
Not every FreeIPA server carries the same work. Certificate authority, DNS, trust, backup and key recovery roles each add memory, disk or network needs on top of the directory and Kerberos baseline. Check these roles first, because they decide which servers need the most headroom.
Integrated CA and the renewal role
The Dogtag certificate authority runs on the servers where you install it, and the first server holds the CA renewal and CRL publishing role by default. That server handles certificate issuance, renewal and revocation list generation for the whole topology, so it needs more memory and disk for certificate records and CRL growth than a plain replica. Confirm in the release documentation which server holds the renewal role in your version, and size that server for it rather than for the average replica.
Integrated DNS service
Running the integrated DNS service adds a BIND process and zone data to each server that carries the role, and it adds query traffic from every client that uses that server as a resolver. Zone size, the number of reverse zones and the query rate from your sites all change the load. Confirm the DNS role placement and the recommended number of DNS servers per client in the deployment recommendations before you fix server counts.
AD trust through Samba components
A cross-forest trust with Active Directory runs Samba components on the trust controller servers, which adds a separate service stack, extra processes and more network exchanges for ID lookups and authentication referrals. The load depends on how many AD users and groups your Linux hosts resolve and how often they log in. Confirm with the trust documentation which servers must run the trust components and which Samba packages and memory they need for your forest size.
Online and full backups
ipa-backup writes either a full backup or an online data-only backup, and a full backup includes the configuration and certificate data as well as the directory. Backup size grows with directory entries, logs and the certificate store, so disk needs to hold several generations plus the working space for the archive. Schedule backups on a server with spare disk and confirm the backup type and retention you need in the backup documentation before you size storage.
Key recovery authority where used
A Key Recovery Authority stores archived encryption keys for users and services, and it runs as an extra role on a server that already holds the certificate authority. Archived keys add records and a dependency on the vault and key store, so the server must have room for them and must be included in backup and recovery planning. Only size for this role if your policy requires key archival, and confirm the KRA placement rules in the release documentation for your version.
Client authentication volume per site
Every Kerberos ticket request, LDAP lookup and SSSD cache refresh lands on the replicas nearest the clients, so the busiest site sets the load for its local servers. Login bursts at shift start, batch jobs and large sudo or HBAC rule sets all raise the rate. Estimate peak login rate per site from your own logs, then confirm with the deployment recommendations how many replicas each datacenter should carry before adding clients to a server.
How to size a FreeIPA deployment step by step
This sequence turns user counts, site layout and outage requirements into a server count, role assignment and host plan that you can verify before any client is enrolled.
Inventory users, groups and hosts per site
List the expected user accounts, groups, enrolled Linux and UNIX hosts, and service accounts for each site, including growth you expect over the life of the deployment. Record the figures in a table with one row per site and a column for each object type. Ask the team that owns HR or directory data to confirm the user counts, since they drive memory and swap requirements later. The step is done when every site has a number for each object type and someone outside the project has signed off on the totals.
Map sites that must work during a WAN outage
For each site, decide whether its users and hosts must still log in, get Kerberos tickets and use sudo or SSH keys when the link to other sites is down. Mark the sites that need local authentication and note which services, such as file access or privileged logins, must continue. Review the result with the business owners of those services. The step is done when each site is labeled as either dependent on a central site or able to operate alone, which determines where replicas must sit.
Choose replicas per site within the recommended range
Using the site map, select the number of replicas for each datacenter. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter and no more than four replication agreements per replica, so check that the planned topology can meet both limits. Confirm the total stays within the 60-server limit for the deployment. The step is done when you have a written replica count per site and a draft replication agreement diagram that respects the four-agreement ceiling.
Assign CA, DNS, trust and backup roles
Decide which replicas carry the Dogtag CA, integrated DNS, a trust controller for any Active Directory trust, and the backup schedule. The recommendations call for at least one replica per datacenter running PKI or DNS if those services are used. Record which server holds the CA renewal and CRL role by default, and note that this role must not disappear during changes. The step is done when every server has a role list and each site has at least one CA or DNS holder where those services apply.
Confirm memory and swap for the target release
Use the official sizing guidance for your FreeIPA release and your user count to set RAM and swap on each server. This guide does not supply memory or swap figures, so request the current table for your release from the FreeIPA project or your platform vendor and compare it with the user totals from step one. Ask the vendor to confirm whether figures differ for the 10,000 and 100,000 user tiers. The step is done when each server has a written memory and swap target that matches the documented figure for its user tier.
Provision dedicated hosts for each server
Build each FreeIPA server on a dedicated host or virtual machine that runs no other application, as the deployment recommendations advise. Set the host name, static addresses and time synchronization before installation, and size disks for the data directory and backups. Keep a record of the hardware or virtual machine profile for each server. The step is done when every server is reachable, has the planned memory and swap, and runs no unrelated workloads.
Verify DNS, reverse resolution and resolv.conf
Before enrolling any client, check that every FreeIPA server resolves forward and reverse, using the host names and addresses you recorded. Confirm that each client's resolv.conf will list at least two DNS servers, and test that both answer for the IPA domain and for reverse zones. Run name lookups from a test client on each site and record the results. The step is done when all forward and reverse lookups succeed from every site and the resolv.conf plan shows two or more DNS servers per client.
Sizing paths for single site, multi-site and AD trust deployments
A single site with a small user base is usually sized by availability rather than by user count. The FreeIPA deployment recommendations advise at least two to three replicas in each datacenter, so a single site normally starts there. The question is how long the site can tolerate authentication being unavailable and who restores a failed host.
- Replica count: Start with two or three servers in the site. Add more only when measured load or availability needs justify it, not because the user total grew slightly.
- Dedicated hosts: Run FreeIPA servers on machines that run nothing else, as the recommendations ask. Keep them away from application hosts that are patched or rebooted on other schedules.
- DNS and CA roles: If you use the integrated DNS or the Dogtag CA, place those roles on at least one server in the site. Confirm which host will hold certificate renewal and CRL publication by default.
- Replication agreements: Keep every replica within the four-agreement limit. A full set of links between two or three servers in one site stays inside that limit.
- Client DNS: Configure at least two DNS servers in each client's resolv.conf so one server outage does not stop name resolution.
Before sizing, confirm the expected login peak, whether the site already runs DNS, which applications depend on Kerberos and how long a failed server can stay down before the business notices. (Illustrative: a site with three replicas and one failed host still has two servers handling logins while the failure is repaired.)
When a deployment must keep authenticating users if another site is lost, the server count grows with each site. Every datacenter needs its own replicas, and the surviving sites must hold enough directory, DNS and CA roles to work without the lost site. The server count follows the failure you plan for, not only the user base.
- Replicas per site: Plan two to three replicas in each datacenter so every site can authenticate on its own after a loss.
- Agreement budget: No replica should carry more than four replication agreements. Map the links between sites before adding servers, because the agreement limit can force a different layout.
- Roles in each site: Where DNS or the CA is used, place at least one of those roles in every datacenter so no site depends on a remote resolver or CA.
- Per-site sizing: Size each site for its own peak load. Do not assume a surviving site can absorb another site's full traffic until you have tested that case.
- Renewal server location: The first server holds certificate renewal and CRL publication by default. Decide where that role lives before a site fails, and plan how it moves if that server is lost.
Confirm the number of sites, which site losses the business must survive, the login and application traffic each site generates and the network links between sites. Then rehearse a site-loss scenario on paper before buying hardware.
An Active Directory trust or a regulated certificate requirement adds roles, not only users. A trust needs an IPA DNS domain that does not overlap with any domain in the AD forest, and a CA that an auditor must review may need dedicated or restricted hosts. These requirements can raise the minimum server count before user volume does.
- Trust-facing servers: Decide which servers handle the AD trust. Keep those roles on hosts you can isolate and monitor, separate from general login traffic.
- CA placement: If a regulated program requires the CA on dedicated or restricted hosts, add servers for that role. Agree the control scope with your assessor before sizing.
- Domain naming: The IPA domain must not overlap with any AD domain. Fixing this early can change the layout, so settle it before hardware is chosen. See the FreeIPA Trusts page for the trust requirements.
- Role-based counts: Count CA, DNS and trust roles separately from login capacity, so a host set sized for logins does not quietly lack a required role.
- Memory per host: Size memory for the heaviest role on each host, and confirm figures against the documentation for your FreeIPA version before buying hardware.
Confirm the AD forest and domain names, the direction of the trust, which CA controls apply, who approves their scope and the expected number of Windows users. These answers decide the minimum number of hosts before any capacity figures are considered.
Sizing limits to confirm for your release
The figures that set FreeIPA server count, client load, memory and storage change between releases and depend on your environment. Confirm each one against the documentation for the release you will install, then measure it in a test environment before you commit to hardware.
Maximum server count
FreeIPA deployments have an upper limit on the number of servers in one topology, and the limit is the first figure to confirm. Check the value stated in the documentation for your installed release, then decide whether your planned replica count leaves room for growth. Ask whether the limit applies to replicas only or to all IPA servers, since the answer changes your layout.
Clients per server
Client load is set by how many enrolled hosts authenticate against each server, not by the user count alone. Measure logins, Kerberos ticket requests and SSSD lookups in a test environment that mirrors your host mix. Use the result to decide how many replicas each site needs and whether clients should be pinned to nearby servers.
Memory and swap for your user count
Memory and swap requirements for 10,000 and 100,000 users depend on the directory data, the services running on the same host and your replication load. Confirm the figures for your release in the documentation, then load-test a server at your target size and watch resident memory and swap activity. Record the peak values, not the idle values, before you order hardware.
Storage growth for logs and backups
Directory data grows slowly, but logs, audit records and backup archives can grow quickly and fill the partitions the server depends on. Measure daily log volume and the size of a full backup on your test server, then multiply by your retention period. Confirm that backup storage sits on a separate volume from the directory database.
Behavior changes in newer releases
A newer release can change the server count limit, memory use, default services or the hardware baseline, even when your current design still works. Read the release notes for every version between your current release and your target before you size new hardware. Repeat the test measurements on the target version, because a figure from an older release is not a reliable guide.
Security and operating constraints that affect server sizing
Sizing a FreeIPA deployment is not only a question of memory and CPU. The deployment recommendations ask for dedicated servers without other applications, so the capacity you plan is capacity for identity services alone. Do not place a FreeIPA server on a host that also runs a build agent, a reporting job or a general application stack, because the memory those workloads take is memory your directory and Kerberos services cannot use during peaks. Plan the swap and RAM numbers for the FreeIPA server as the only tenant, and confirm with your platform team that the host image, monitoring agents and backup tooling fit inside that budget. The first server also carries extra load by default. Its role in certificate renewal and CRL publication means it can be busier than its peers during renewal windows, so give it headroom rather than sizing every replica identically. Before you change the layout, check which server holds that role, because moving it during a migration changes where the work lands. Restoring an outdated backup into an active replica topology can break replication, so any restore plan must be sized and rehearsed as a recovery exercise, with the restore target isolated from production replicas.
Security releases also need room in the capacity plan. The FreeIPA 4.13.4 release notes describe a stabilization release that fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials. Schedule that kind of patch window before you commit to a server count, because each server you take out of rotation for an upgrade must be covered by the others, and a topology with the minimum number of replicas per site has little slack for that. Confirm how your team will drain a replica, patch it and verify replication before returning it to service. If your environment requires FIPS mode or a hardened build, confirm two things with your vendor and your own test lab before you size hardware: whether the exact FreeIPA version and operating system combination you plan to run is supported in that mode, and how the cryptographic overhead changes CPU load and login latency under your expected peak. Ask for measured figures from a test run instead of assuming the cost is negligible.
Questions teams ask about FreeIPA sizing and hardware
What determines the number of FreeIPA servers I need?
The server count follows from where users and clients authenticate, how many sites you run, and which roles each server must carry. The FreeIPA deployment recommendations advise two to three replicas in each datacenter, so a multi-site estimate starts with the site count. Each replica should have no more than four replication agreements, which limits how many peers one server can link to and shapes the topology. Roles add further servers: at least one replica per datacenter should run the CA or DNS if you use them. Confirm the current guidance for your release in the deployment recommendations before fixing a number.
Is a single FreeIPA server enough for a small organization?
A single server can support a lab or pilot, but in production it is a single point of failure for logins, Kerberos tickets, certificates and DNS. The recommendations call for dedicated servers and at least two replicas in each datacenter, so one server leaves no failover path. Clients should also list at least two DNS servers in their resolver configuration, which only helps if a second server exists. Backups protect data but do not restore availability. The first server also handles certificate renewal and CRL publication by default, so losing it is more than an outage. Test what breaks during a server loss in a test build before you decide.
How do I estimate memory for a large user base?
Memory need depends on directory size, the number of hosts and services, replication traffic, whether the CA and DNS run on the same server, and how clients query the directory. No memory figure is given here, and any number from a generic guide should be checked against your own load. Build a test environment, load a representative set of users, groups, hosts and policies, then measure memory use and swap during logins, enrollment and replication. Repeat the test with CA and DNS enabled. Plan headroom for growth and for the peak during replica initialization. Ask your team to confirm minimum and recommended memory in the installation documentation for your platform.
Can our own team size a FreeIPA deployment without outside help?
Yes, if your team can build a test environment, load representative data and read the documentation for your release. Many in-house efforts skip the measurement step and rely on assumptions. Sizing also covers topology, site mapping, role placement, DNS locations and failure tests such as losing a site or the CA server. In-house work costs staff time for each step, plus test infrastructure and the time to learn the product. An outside partner charges for the same activities against a written scope. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside your infrastructure, but it does not issue audit reports or certifications.
What does a FreeIPA sizing engagement need from us?
Prepare the inputs that drive the design before work starts:
- User and client counts, with growth expectations and service accounts
- A site map showing network links, latency, and where users and machines sit
- A backup policy covering retention, full versus online data-only backups, and storage location
- Trust requirements, such as whether you need a cross-forest trust with Active Directory, which requires a DNS domain that does not overlap with the AD forest
- Applications that authenticate, DNS and CA requirements, and any compliance obligations
Also provide access to a test environment, and ask that the sizing assumptions appear in the written scope so that later changes can be traced to them.
What drives the cost and effort of FreeIPA sizing work?
Cost follows scope: the number of sites, the number of servers to model, the integrations, the trust and multi-factor requirements, and how deep the load testing goes. The main components are the design workshop, the test build and load testing, documentation, and handover. The design and first test are one-time work. Costs recur when you add sites, grow user counts or change roles, so ask whether later re-sizing is included or quoted separately. DeployOpen does not publish a price list, and a quote follows the written scope. Ask for itemized deliverables, the assumptions about your environment, who supplies test hardware, and which changes trigger a new estimate. Timelines depend on access to infrastructure and internal approvals.
How DeployOpen scopes FreeIPA sizing work
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, so FreeIPA sizing is handled as part of the same work. We start from your user counts, client estimates, sites and existing directory data, then agree the server count, memory and hardware in writing before any build starts.
How we scope
- Written scope lists user, group and host counts, client numbers, sites and the workloads each FreeIPA server will carry.
- Sizing assumptions for RAM, swap, CPU and disk are recorded per server role, with the figures your environment must confirm.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts, with a quote following from that scope.
How we build
- We confirm the replica count against the 60-server limit and the replication agreement guidance for each datacenter.
- Test hosts are built to the agreed specification and checked for memory use under representative enrollment and login load.
- Layout changes such as adding a replica or moving a CA or DNS role are tested in a non-production copy before production.
How we hand over
- Handover includes a sizing record showing the design basis, the hardware specification and the reasons for each server count.
- Runbooks cover growth triggers, when to add a replica, and the checks to run after resizing a server.
- Your team receives the verification results, so the sizing decisions can be reviewed and repeated by your own engineers.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for sizing reviews as your user base grows.
- Retainer reviews can re-check server memory, swap and replica counts after FreeIPA upgrades or new client rollouts.
- We recommend confirming current limits and hardware guidance with the FreeIPA project and your platform vendor before each review.
