Should We Host Rails Authentication Centrally or Run the Full Stack Locally?
Asked by
MellowPine42
Our application currently consists of a Ruby on Rails authentication service, a React frontend, and a Flask/Python API. At the moment, each developer runs all three services locally. I'm considering moving the Rails authentication service to a shared Linux development server so developers would only need to run React and Flask locally. The goal is to reduce local resource usage and simplify setup. Is this a sensible approach for a team? If so, should each developer receive an isolated Rails instance with separate environment variables and database state, or would a single shared authentication service be acceptable? I'm also concerned about debugging, performance, migrations, authentication cookies, CORS, CSRF, OAuth callbacks, configuration drift, and the possibility that one developer's changes could disrupt everyone else. How have other teams handled a setup like this?
Answers
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.
Reply to this answer
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.
Reply to this answer
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.
Reply to this answer
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.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions