Should We Host Rails Authentication Centrally or Run the Full Stack Locally?

I’d avoid putting everyone on one shared Rails development instance. A migration, configuration change, branch deployment, or bad test data could affect the entire team and make failures difficult to reproduce. If the server approach is necessary, give each developer a separate Rails process, database, configuration, and ideally a separate environment or feature-branch instance. A single shared instance is only reasonably safe when the service is nearly static.

The main risk with a remote auth service is hidden state coupling. Every local test would depend on that server’s uptime, database contents, configuration, and current branch. One person’s migration or test could break somebody else’s login flow. You’d also need to carefully handle CORS, CSRF, cookie domains, SameSite settings, OAuth redirect URLs, secrets, and access to logs. Contract tests can cover many service-integration cases, while each developer keeps a smaller isolated environment for the workflows that require real authentication.

The simpler option is usually to containerize the whole stack with Docker Compose. Put Rails, React, Flask, and their dependencies in one versioned setup so a developer can bring up an isolated environment with one command. That avoids shared state and keeps local behavior close to production. Dev containers can also standardize language versions, package managers, editor extensions, and startup scripts, which tends to be easier than documenting a long installation chain.

If local machines genuinely cannot handle all three services, a per-developer remote environment is a reasonable compromise. Run each developer’s services in separate containers or namespaces, assign distinct ports and databases, and automate provisioning and teardown. I still wouldn’t share one active auth instance across developers. Even with remote environments, keep a lightweight Compose setup available so bugs can be reproduced in a fully isolated stack.