Your First Aerobase Pilot: One Realm, One App, One MFA Policy

The fastest way to evaluate Aerobase isn’t to model your whole company. It’s to stand up one working environment, connect one real application, and prove one real authentication policy.

That’s the whole story of a good first pilot — and the failure mode that ruins most IAM evaluations is trying to do all three at scale on day one.

Why most IAM pilots fail

Pilots collapse for predictable reasons, and almost none of them are about the IAM product itself:

• Too many applications at once — every integration introduces new claims, new logout flows, new edge cases. Five of them in parallel means none get fully proven.
• Too many user sources — connecting AD, an HRIS, a customer database, and Google Workspace in week one guarantees you’ll spend the rollout debugging directory plumbing instead of evaluating the product.
• Too many policies — adaptive MFA, step-up auth, risk scoring, and password policies all interact. Stacking them before any of them is observed isolates nothing.
• No operational learning — the team learns the admin console but not the upgrade path, log story, or backup workflow. The pilot succeeds and production stalls.

A focused pilot replaces breadth with depth: one realm, one application, one authentication policy — exercised end-to-end including the recovery and support paths.

The pilot path: install → realm → app → MFA

Aerobase ships as a self-hosted omnibus package built on Keycloak (currently Keycloak 26.6), so all four pilot steps run on infrastructure you already own.

Step 1 — Install on the OS your team already runs

Pick the install path that minimizes new operational surface area:

• RPM (CentOS / RHEL / Rocky / Fedora) — sudo yum install ./aerobase-26.6.2-1.centos.rocky10.x86_64.rpm from the downloads page. Bundled OpenJDK 21 and Postgres; systemd integration; native aerobase-ctl lifecycle commands.
• DEB (Debian / Ubuntu LTS) — same bundle, dpkg -i. arm64 and amd64 packages both ship.
• Docker — community image for fast spin-up. Good for the pilot, not for production HA.
• Windows MSI — included with the Enterprise plan; useful when the rest of the stack is on Windows Server.

The package version is pinned to the Keycloak release it embeds — running aerobase-26.6.2-1 means you’re on Keycloak 26.6.2 underneath, with the same SPI surface, same admin console, same operational primitives. (Aerobase downloads)

Step 2 — Create one realm and stop there

Realms are tenant boundaries. The temptation is to mirror your org chart on day one; resist it. A pilot realm holds:

• one administrator (you)
• a small set of test users (5–20)
• one application client (the next step)
• one authentication flow (the default is fine until step 4)

Federation against AD/LDAP/Azure AD can wait — local users let you exercise enrollment, password reset, and admin recovery without dragging directory ops into the pilot.

Step 3 — Connect a real application

Toy demos don’t tell you anything you didn’t already believe. Pick one application your team uses and integrate it as the pilot client:

• Internal Java/Node/Python app — use the OIDC adapter for your language; the Securing Apps guide covers each. About an hour of setup for most modern frameworks.
• A SaaS that supports SAML — Slack, GitHub, Atlassian, your CRM. Configure Aerobase as the SAML IdP. This tests the realm metadata, signature certificates, and assertion mapping end-to-end.
• A custom internal tool with no auth today — if you have one, this is the highest-value pilot because it forces the team to make real authorization decisions, not just relocate existing ones.

What to verify before moving on:

• The login redirects cleanly. ✓
• Logout actually clears the session in both Aerobase and the app. ✓
• A new user invited through the Aerobase admin console can complete first-time login. ✓
• A password reset flow works end-to-end including email delivery. ✓

Step 4 — Turn on one MFA policy

One policy. Not three. The two practical first choices in 2026:

• TOTP (authenticator app) — universal, no SMS delivery cost, and well-supported in user devices. The default Aerobase TOTP flow enforces enrollment on first login and verifies on subsequent logins.
• WebAuthn / passkey — phishing-resistant, friction-light. Aerobase 26.6 ships zero-downtime updates and updated WebAuthn ergonomics; a small pilot is the right time to learn whether your users’ devices are ready for it.

What to test:

• Enrollment on first login. ✓
• Authentication on subsequent logins. ✓
• Recovery when a user loses their factor. This is the step every pilot skips and every production rollout regrets. Verify the admin reset path (and document it). ✓
• Bypass policy for break-glass admin recovery (aerobase-ctl recover resets the master realm admin if MFA enrollment locks you out). ✓

What a good pilot proves — and what it doesn’t

A focused first pilot answers:

• Can admins install and operate the platform on the team’s preferred OS?
• Does one user source work cleanly end-to-end?
• Does one application login flow stay stable across login, logout, and password reset?
• Are MFA and recovery understandable to the team that will support them in production?
• Can the team picture a credible production rollout path?

It explicitly doesn’t answer:

• Will the directory sync from AD scale to 50,000 users? (Answer: yes; not the pilot’s job to prove.)
• Does the policy engine handle our most exotic conditional access rule? (Save it for production.)
• Should we use Aerobase for customer identity too? (Different conversation; pilot the workforce side first.)

Production checklist before going live

Once the pilot is green, the questions that matter for production are usually operational, not feature-level. Confirm you have answers for:

• Backup and restore — Postgres-backed; standard pg_dump works. Test the restore path.
• TLS and hostname strategy — pick a hostname now, certificate ownership early.
• Admin access rules — admin-only realm separate from end-user realms is the standard pattern.
• Upgrade path — Aerobase tracks Keycloak LTS releases with backported CVEs; the omnibus handles rolling upgrades. Validate it once in staging.
• Log visibility — centralize them (Loki, Splunk, CloudWatch) before production.
• Support ownership — who owns the SLA? If it’s not your team, the Aerobase Basic plan covers it for $690/month flat.

Frequently asked questions

How long does a focused Aerobase pilot take?

The install-to-first-login path is a single afternoon for most teams. The full pilot — including MFA, recovery testing, and a real application integration — is usually a one-week effort with one engineer half-time.

Do I need a license to evaluate?

No. The Open Source plan is free forever and includes the same packages used in production. The Basic plan adds SLA-backed support, LTS packages with CVE backports, and a cloud test instance.

Should the pilot run on bare metal or Docker?

Docker is fine for the pilot loop because it lets you spin up and tear down freely. Production should run on the omnibus package on a Linux VM (or pair, for HA) — the operational surface is the same, and Docker doesn’t buy anything for a long-running production IAM service.

What if the pilot user count grows?

Aerobase doesn’t bill per user. A pilot that grows from 20 users to 20,000 doesn’t change the support plan — it just changes the hardware footprint, which stays small (sizing guide).

Where does MFA enrollment recovery live?

Inside the admin console — an admin can reset a user’s MFA factor on demand. For master-realm admin lockout, aerobase-ctl recover '<new-password>' re-enables the master realm, ensures the admin user exists, and resets the password. Document both paths during the pilot.

Bottom line

The best Aerobase pilot is one real realm, one real app, and one real security policy. That’s enough surface to prove the platform, expose real operational questions, and give finance and security a credible answer about what production looks like.

Start from the downloads page, and keep the public Server Administration Guide and Securing Apps guide open while you work through the four steps. If you want SLA-backed help during the pilot, the Basic plan includes a monthly consulting allotment alongside the support portal.