Make repository deployable on Railway #189
Open
+904
−35
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add comprehensive Railway configuration to enable deployment directly from the repository without using pre-built templates or container images. Changes: - Add railway.toml for each service (agent, UI, desktop) with Docker build configs - Add root railway.json for project-level configuration - Enhance .env.example files with Railway-specific guidance and internal URLs - Update server defaults for production Railway deployment: - UI server: Auto-bind to 0.0.0.0 in production for load balancer compatibility - Desktop: Use PORT environment variable (default 9990) - Add RAILWAY_DEPLOYMENT.md: Comprehensive 200+ line deployment guide covering: - Step-by-step service setup - Environment variable configuration - Railway internal networking (service.railway.internal) - Troubleshooting common issues - Cost optimization and security best practices - Add RAILWAY_QUICKSTART.md: 15-minute quick-start checklist Configuration ensures deterministic builds using: - Existing Dockerfiles with proper build context (packages/) - Service discovery via Railway's internal DNS - Environment variable defaults with Railway reference variables - Proper resource allocation recommendations All changes maintain existing application behavior - only deployment configuration and sensible production defaults added.
Railway doesn't support custom dockerContext in railway.toml. The build context is automatically set based on the Dockerfile location. For monorepo support, the cleanest approach is to use the repository root as the build context for all services. Changes: - Remove invalid 'dockerContext' field from railway.toml files - Remove conflicting railway.json at repository root - Update all Dockerfiles to copy from 'packages/' paths (repo root context) - Update docker-compose files to use repo root context for consistency - Update documentation to clarify Railway auto-detects from railway.toml - Remove manual Root Directory configuration from deployment guides Docker build context changed from: Old: context = packages/, COPY ./shared, COPY ./SERVICE New: context = repo root, COPY packages/shared, COPY packages/SERVICE This ensures consistent behavior across: - Railway deployments (uses railway.toml) - Docker Compose deployments (uses docker-compose.yml) - GitHub Actions CI/CD (builds from repo root) All builds now use repository root as the Docker build context.
…lway.toml Railway's auto-detection doesn't work with railway.toml files in subdirectories of a monorepo. For monorepos, Railway requires explicit UI configuration for each service. Changes: - Remove service-specific railway.toml files (caused "build plan" errors) - Add documentation-only railway.toml at root with configuration reference - Update deployment guides to use Railway UI configuration: - Create Empty Project first - Add each service manually from GitHub repo - Configure Dockerfile Path in Settings → Build - Add Watch Paths to trigger builds only for relevant changes - Configure all environment variables via UI - Clarify deployment order (desktop first, then agent, then UI) - Add warning about manual configuration requirement for monorepos Railway Configuration Method: - No auto-detection - Manual service creation via UI - Explicit Dockerfile path for each service - Watch paths for optimized builds (only rebuild when service changes) This approach ensures Railway builds each service correctly without confusion from multiple configuration files.
|
Ryvn Preview Creating preview This comment will be automatically updated with preview details. |
…text Railway sets the build context to the directory containing the Dockerfile. When Dockerfile path is packages/SERVICE/Dockerfile, context becomes packages/SERVICE/, causing COPY packages/shared to fail. Solution: Create Dockerfiles at repository root (Dockerfile.agent, Dockerfile.ui, Dockerfile.desktop) that Railway can use with repo root as the build context. Changes: - Add Dockerfile.agent - Agent service with repo root context - Add Dockerfile.ui - UI service with repo root context - Add Dockerfile.desktop - Desktop service with repo root context - Update RAILWAY_QUICKSTART.md to use root-level Dockerfiles - Update RAILWAY_DEPLOYMENT.md to use root-level Dockerfiles - Update railway.toml documentation Railway Configuration Now: - Dockerfile Path: Dockerfile.agent (not packages/bytebot-agent/Dockerfile) - Dockerfile Path: Dockerfile.ui (not packages/bytebot-ui/Dockerfile) - Dockerfile Path: Dockerfile.desktop (not packages/bytebotd/Dockerfile) - Build context: Repository root (automatic when Dockerfile is at root) - All COPY commands work correctly This fixes the "Error creating build plan" issue.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.