No. Dirless is a full Linux identity management system that works entirely without AWS. You can add users directly through the web portal and they become native Linux identities on every enrolled server. AWS IAM Identity Center sync is an optional feature for teams who already use it - not a requirement.
No. The agent has no AWS dependency - it only needs network access to the Dirless backend over HTTPS. Agents run on any Linux host: on-premises, other cloud providers, bare metal, or VMs anywhere. Only the syncer needs to run on an EC2 instance (to access the instance role for IAM credentials).
Nothing bad. The agent maintains a local database on each host. NSS lookups read from it directly - no network call at query time. If the backend is unreachable, the last-known-good snapshot stays on disk and identity resolution continues working normally. Users already on the host stay logged in; new lookups still resolve. The only thing that stops during an outage is pulling fresh changes from Identity Center.
Yes. In addition to users synced from IAM Identity Center, you can add local users directly through the web portal. These users are encrypted with the same age keypair and distributed to all enrolled hosts just like cloud-sourced users. This is useful for service accounts, contractors, or anyone who needs a Linux identity but isn't in IdC.
No. Dirless handles the identity layer - making users exist in the OS - which is the
prerequisite for SSH, so your existing setup (authorized_keys, a PAM module,
an AuthorizedKeysCommand) keeps working unchanged for both cloud-sourced and
locally-added users.
If you want to stop managing keys entirely, Dirless also ships
SSH certificate access: users run
dirless-connect ssh register once on their workstation, then
dirless-connect ssh login issues short-lived certificates that let them reach
any enrolled host - no authorized_keys files to distribute, and access expires
on its own. Host-based access control decides who can log in where.
The backend assigns UIDs and GIDs deterministically and stably for all users - whether synced from IAM Identity Center or added through the web portal. Once assigned, they never change, even if the user is removed and re-added. This is critical for shared filesystems where file ownership is stored numerically. You never end up with a UID recycled to a different user.
Yes. Dirless is fully self-hostable. The backend is a single static binary with a TOML config file. Point your syncer and agents at your own URL. The protocol between all components is identical regardless of who operates the backend. Customers who need full control over their infrastructure or air-gapped deployments use this path. The self-hosting guide walks through the components and what each one needs.
Yes. Every component of the platform - the backend, the syncer, the agent, the CLI, the NSS module, and the libraries underneath them - is open source under Apache-2.0 at github.com/dirless. You can audit exactly what runs on your hosts, build the binaries yourself, or run the whole stack on your own infrastructure. The hosted service is the same code, operated for you.
Then leaving should be one command, and it is:
dirless-cli export writes every user, group, and
SSH key back out as JSON, standard LDIF you can load into any LDAP server, or flat
passwd-style files. Identity systems are sticky enough without vendor tricks -
your directory is yours, going in and coming out.
The documentation covers every direction: exporting your directory, importing it back (or restoring a backup), migrating in from FreeIPA, and running the whole stack yourself if leaving the hosted service is all you want.
Yes. Dirless does not ship an LDAP server, on purpose - but
dirless-cli export --format glauth renders your directory as a ready-to-run
config for glauth, a proven single-binary
LDAP server you run on your own network. Jenkins, Gitea, VPNs, and NAS boxes get their
LDAP directory; you still don't operate LDAP infrastructure. The
LDAP compatibility guide has the full recipe.
Not in readable form. At enrollment time, the agent generates an age keypair and sends only the public key to the backend. The backend encrypts every snapshot before storing or serving it. The private key lives only on your host - we never see it. Even if our backend were compromised, an attacker would only find encrypted blobs they cannot decrypt.