Skip to main content
Starting Tuesday, October 20, 2026, Flox CLI commands that resolve packages will require authentication with a free Flox account. The change arrives with Flox 1.19.0 and applies to older versions too.

​
What’s changing

Several Flox commands have always run through Flox cloud services for search, indexing, package resolution, and environment operations. Beginning October 20, every command that resolves packages against the Flox catalog will require authentication. A command resolves packages when: Changing [vars], [hook], [profile] or [services] locks the environment without contacting the catalog, so it needs no sign-in. Installing a flake reference or a Nix store path doesn’t use the catalog either. flox init creates an environment without a sign-in. In a project where Flox detects Node.js, Python or Go, its package suggestions need one.
Probably not, and if you do it’s one command. Find the row closest to how you use Flox.

​
What stays the same

flox activate does not require authentication for an environment that already has a current lockfile. If your daily workflow or CI pipeline simply activates an existing environment that relies on public packages, nothing changes for you. flox search and flox show stay open too, so browsing the catalog needs no account. So does pulling a public environment with flox pull, and so does flox build when the environment’s lockfile is current. Private packages and environments continue to require authentication as they do today, and so does publishing. Nothing about those changes.

​
Why we’re doing this

Flox has grown from an open source CLI into foundational infrastructure used across developer machines, CI, build systems, and increasingly AI agents. As usage has grown exponentially, so has our responsibility to operate the cloud services behind Flox reliably and to keep improving them based on how they’re actually being used. Requiring authentication for the commands that interact with those services gives us a better foundation for understanding those workflows, operating the service reliably, and investing in the parts of Flox people depend on most. It also gives us better standards around abuse prevention. We’re intentionally keeping flox activate available without an account for public environments. If you’re consuming an environment someone else maintains, you do not need to create an account just to use it. To be clear: this is not a paywall. The free tier keeps the same capabilities it has today. You’ll need a free account for the commands above, not a paid subscription.

​
Signing in

FloxHub has made it easy to login. How you sign in depends on where you’re running Flox.
Run flox auth login and follow the browser prompt. You can log in with an existing GitHub, Google, or GitLab account. If you don’t have an account, the same flow creates one.
You do this once per machine. Paid customers can also authenticate with their own SSO provider — see Enterprise SSO.
You can also sign in on the web at hub.flox.dev.

​
CI and automation

Automation breaks quietly, so it’s worth handling before anything else. Two ways through:
  • Commit your lockfile. A pipeline that activates an existing environment against a committed manifest.lock never calls the catalog, so there’s no token to manage. You get reproducible builds and one less network dependency out of it, which is worth doing anyway.
  • Or give the pipeline a token. Pipelines that run flox install, flox upgrade, or any of the other commands above do reach the catalog. So does flox build when the lockfile it’s building against is out of date. Issue a token in FloxHub and set it as FLOX_FLOXHUB_TOKEN from your CI platform’s secret store. The pipeline or agent then runs Flox commands without user interaction.
A personal access token works on any account, including a free personal one, and acts as you. A service account token belongs to an organization instead, so the pipeline keeps running after someone changes teams or leaves. The CLI reads both from the same variable. The CI/CD tutorial covers setup on specific platforms.
Service account and personal access tokens need Flox CLI 1.14.0 or newer. Older releases reject the token as invalid and clear it, so the pipeline fails as though it were never set. Check with flox --version, and see installing Flox to upgrade. If the pipeline can’t upgrade, commit its lockfile instead.

​
GitHub Actions

On GitHub Actions, pass the token to flox/install-flox-action as floxhub-token. The action logs Flox in before it runs any other Flox command, and logs out when the job ends.
.github/workflows/ci.yml
The floxhub-token input needs install-flox-action v2.7.0 or newer. The @v2 tag already includes it. If you pin an exact version or a commit, move the pin forward.

​
Older Flox versions

The Flox catalog enforces the requirement, so from October 20 it applies to every Flox version, not only 1.19.0. Staying on an older release doesn’t postpone it. What you need depends on the version you run:

​
FAQ

No. Flox has always had a free tier and we keep adding to it. You need a free account, not a paid subscription.
If your pipeline uses one of the commands listed above, add a personal access token or a service account token to your CI secrets before October 20. Pipelines that only activate an existing environment against a committed, current lockfile carry on unchanged.
Tuesday, October 20, 2026, the day Flox 1.19.0 ships. The requirement applies to every Flox version from that date, so older versions need a sign-in too.
Commands that resolve packages fail with an error that tells you to run flox auth login. Run it, then run the command again. Signing up takes under a minute.
When you aren’t logged in, Flox reminds you to run flox auth login. To turn the reminder off:
Or set FLOX_AUTH_NOTIFICATIONS=false in the environment, which is usually easier in CI. Both need Flox 1.15.0 or newer. They silence the reminder only. A command that needs a sign-in still fails with an error until you log in.
Yes. FloxHub Enterprise runs on your own infrastructure. Email hello@flox.dev for more information.