The Issue

Every product eventually needs to know who’s knocking - login, registration, account recovery, and OAuth for everything that comes after. It’s also the one piece of the stack that only a true amateur would hand-roll, which leaves two roads: a monthly bill from a hosted identity vendor you’ll struggle to ever leave, or a full sprint of assembling random Open Source parts into something that mostly works. Ory is the credible third option - but “just get it running” is left as an exercise in madness for whichever engineer drew the short straw this week.

Our Take

You do the pragmatic thing when you need to start supporting user logins, and pick Ory because it’s rock solid and Open Source. Then you open the docs and a few hours later… you’re ready to give up all your worldly possessions and start a new career in rural potato farming. You’ve got a handful of YAML files with dozens of (super) critical authentication settings, ten overlapping gateway routes for incoming requests, and seventy-odd stack configuration values that all have to agree with each other - and none of it has anything to do with what you actually care about. Finally you’ve technically got everything running - but then a user has the audacity to click “Sign In” and the login redirect hits an infinite loop before eventually coughing up some obscure error message… now it’s 3:00 a.m. and you’re re-learning which service is supposed to hand the browser which cookies at each point in the world’s most ridiculous five-handed juggling act. Production-grade identity should not cost a sprint of plumbing before the first user can even sign up.

We wanted that whole entire sprint back, so… we solved the problem. Today we’re announcing FiMOr - Fifteen Minute Ory. It’s Open Source, it’s on our GitHub, it’s up-to-date, and it does one job: take a bare host and a domain name and turn them into a working Ory identity stack in Docker Compose, in less than fifteen minutes.

What is FiMOr?

FiMOr is a production-grade Ory deployment that is completely pre-wired to provide a foundational authentication stack and several additional important services for Operators. Kratos owns your users’ sessions along with registration, login, verification, recovery, and settings. Hydra is your OAuth2 server, issuing JWT access tokens and handing login and consent off to Self-Service. The Self-Service UI is included, plus an Admin UI comes along for the ride too - so the whole round trip works the moment the stack goes live.

The project is built from five independent Compose modules - pg, ory, net, extras, and debug - so you can take what you need and leave the rest. Every piece of configuration is rendered from templates and environment variables each time the stack starts, which means there’s one file to edit and nothing to keep in sync by hand. And since the edge layer is built on our TIBIA gateway, existing TIBIA users already know how to onboard. Like SALLY, FiMOr is a building block and not a black box: it’s ready to run as-is, but every knob is still within reach when you decide you want to turn it.

(black lines to services are public, yellow are private)

Here’s the whole picture, by module:

• net - Traefik, the only container in the stack with published ports.
• pg - Postgres, plus the Kratos and Hydra migrators that prepare their schemas on the way up.
• ory - Kratos and Hydra themselves, along with a config bridge that renders their configuration from your environment.
• extras - the Self-Service UI your public users see and the Admin UI for Operators
• debug - holds whoami, mailslurper, and an OAuth2 consent mock - all of which are bring-up scaffolding, only.

Why We Built It

This is the “hard delivery” angle, but unquestionably with the highest stakes yet. Identity is the part of every project that gets put off even longer than the social media campaign, exactly because it’s also the part you can least afford to get wrong - the blast radius on a mistake here is every one of your users and all of their data. Every new product has a “we need accounts” moment, and every time it quietly eats the first week. Not because Ory is bad software, but because we had to re-learn how all of the pieces fit together every time we stood up a new authentication system: session cookies scoped to the wrong level of sub-domain, SameSite and Secure flags that behave differently on every environment, and an authorized redirect URL list that has to be edited by hand for every new hostname, every staging copy, and every “quick” demo site.

That’s the real cost, not installing Docker and running a few Ory containers - it’s the absurd configuration sprawl of getting an entire critical security realm hooked up correctly. And it’s why the fifteen minutes matters more than it sounds. A stack that takes a weekend to stand up is a stack nobody ever rebuilds, and a stack nobody rebuilds is one nobody has ever standardized - the exact wrong direction to go with your authentication systems. Make it low friction enough and “just stand up a new one” becomes a normal Tuesday afternoon instead of a permanently held breath. We chose Ory for the same reason we choose other parts of our project stack: it’s Open Source, it’s standards-based, and it’s something you can leave - no per-user pricing and no vendor holding your user table hostage. You own the Operations, but FiMOr rm -rf’s all of the traditional excuses for not doing this with your authentication layer.

It also fills the last big hole in the family - SOCKS serves your files, TIBIA puts them on the internet safely, and KARPAL schedules your workloads. What we were missing was a single domain-wide source of truth for user identity - one place that knows who every user is, issues the tokens for it, and gets the final say - instead of each service keeping its own particular idea of who’s who. We’ll know FiMOr worked the next time an engineer is assigned to “add auth” and doesn’t immediately put up an “Out of Office” sign on their desk.

What’s In The Box

• AuthN and OAuth2, Ready To Go: Kratos handles authentication and Hydra is a full OAuth2 server issuing JWT access tokens, but AuthZ is not included by default: FiMOr is based on Ory so Keto, Oathkeeper, and Talos are the natural (but not required) solutions for any AuthZ, Auth Proxy, or Agent token needs.
• Secrets You Don’t Have To Invent: ./fimor init generates random secrets with OpenSSL for you, and ./fimor up flat-out refuses to run while any environment placeholders remain.
• Debug Services: An OAuth2 consent mock, mailslurper to catch verification and recovery emails, and a whoami canary give you everything you need to walk the flows end to end - then remove them before launch.
• Host Bring-Up Scripts: Installers for Docker, plus ufw and swap configuration, for Debian and Ubuntu. They’re optional, and only for a fresh machine.
• Separate Public and Private Lanes: Admin APIs, the Admin UI, and the Traefik dashboard are served only on the private HTTPS port (8443 by default). Everything your users touch is on 80 and 443.
• Staging Certificates First: The stack starts in BRINGUP MODE with Let’s Encrypt staging certificates, so you can prove your DNS and routing work before you trip a production rate-limit. Flip the resolver to production once everything checks out.

Honest Limitations

We’re dedicated to talking about the soft underbelly of our creations, and an identity stack has a few that matter more than most:

• The admin APIs, the admin UI, and the Traefik dashboard have no authentication at all. The private lane is separate, not secret - it’s only as private as your firewall makes it.
• The debug services are for bring-up only. mailslurper exposes every email the stack sends, including verification and recovery codes, whoami echoes request headers, and the public-facing consent mock takes its client secret on the command line. Remove all three and delete your testing client before real users arrive.
• Traefik mounts the Docker socket, so compromising that container compromises the machine.
• Docker publishes ports through its own firewall rules, which can bypass ufw. Verify what’s actually exposed from an external machine.
• The default Postgres password is public. Set your own before the stack ever sees traffic.
• Keep .env.local, pg/data/, and net/acme/ out of git - they hold your secrets, your database, and your certificates.
• It’s only one host, so there’s no host-level redundancy. If the machine goes, everything goes.
• Doing it - Ory, Postgres, and Traefik versions are yours to move (26.2.0, 18.3, and 3.6 today). Identity is exactly the kind of software you don’t want to leave unpatched, and it is not zero effort.

Get It / What’s Next

FiMOr is available, now, on our GitHub. You’ll need Docker with Compose, curl, openssl, and jq, plus a domain with its DNS A records pointed at the host and public ports 80 and 443 reachable for certificate issuance. Then:

git clone https://github.com/315Concepts/fimor-auth
cd fimor-auth
./fimor init
# set SERVICE_DOMAIN and ACME_CERTIFICATE_EMAIL in .env.local
./fimor up

That brings everything up in staging mode. Walk the flows with the debug services, then set a few production .env.local values and run ./fimor down && ./fimor clean && ./fimor up to go live. That’s… it. ChatGPT - Can you help me get this running?

The README and its companion docs cover the full architecture, operations, networking, and firewall guidance for the project. As with the rest of the family, the code is out in the open so you can use it, break it, and improve it. If you hit a rough edge, find a gap in the debug flow, or want FiMOr to do something it doesn’t yet - open an Issue or send a Pull Request. The best fixes tend to come from someone else’s “oh, that’s why nobody does it that way” moment.

And don’t worry - Kratos and Hydra have never once leaked a recovery code. That’s the debug services’ job, which is exactly why they get removed before launch.