Files
2026-04-10 12:02:36 +02:00

254 lines
5.0 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 🧩 What the Project Page Is
The Project page represents one isolated application environment on Railway.
Think of a project as:
> A self-contained box that holds all services, databases, configs, deployments, logs, metrics, and environments for one product or system.
### Example Structure
```
One project = spark-screen
├── Go backend
├── Frontend (Vite/Solid)
├── PostgreSQL
├── Redis
├── Worker / cron
└── Preview + Production environments
```
## 🗺️ Main Layout of the Project Page
Visually, the project page is built around a canvas + side panels model.
### 1️⃣ Project Canvas (Center)
This is the graph view you see first.
### What it shows:
- **Each service as a card** (app, db, worker, etc.)
- **Lines showing relationships** (e.g. `backend → database`)
- **Deployment status per service**
### Each card usually displays:
- **Service name**
- **Source** (GitHub repo, Dockerfile, template)
- **Current deployment status** (running, building, failed)
- **Quick access to logs & settings**
> 👉 This canvas is not just visual — it reflects actual runtime dependencies.
### 2️⃣ Services (Core Units)
Each box on the canvas is a Service.
A service can be:
- **Web app** (Go, Node, Bun, Python, etc.)
- **Background worker**
- **Cron job**
- **Database** (Postgres, Redis, MySQL)
- **Custom Docker container**
Clicking a service opens its Service Detail Panel.
## 🔍 Inside a Service (Very Important)
When you click a service, you get several tabs:
### ⚙️ Settings
This is the brain of the service.
You configure:
- **Source**
- GitHub repo (via GitHub App)
- Branch
- Root directory
- **Build**
- Build command
- Start command
- Dockerfile (optional)
- **Resources**
- CPU / RAM limits
- **Networking**
- Public domain
- Internal service-to-service URLs
> **How it works:** Any change here triggers a new deployment. Railway stores this config and applies it at runtime.
### 🔐 Variables (Environment Variables)
This is where Railway shines.
Keyvalue environment variables
Can be:
- **Service-specific**
- **Shared across the project**
- **Environment-scoped** (prod / preview)
### Examples:
```
DATABASE_URL
REDIS_URL
JWT_SECRET
PORT
```
> **Behind the scenes:**
>
> - Injected into the container at runtime
> - Never hardcoded into images
> - Securely stored and masked in UI
### 📦 Deployments
This tab shows:
- **Full deployment history**
- **Commit hash** (if GitHub)
- **Build logs**
- **Runtime logs**
- **Rollback button**
> **How it works:**
>
> 1. Git push (or manual deploy)
> 2. Railway pulls code
> 3. Builds container (Railpack or Docker)
> 4. Starts new instance
> 5. Old one is replaced (zero-downtime when possible)
### 📜 Logs
### Real-time logs:
- **stdout / stderr**
- **Build logs**
- **Runtime errors**
Logs are:
- **Per-service**
- **Per-deployment**
- **Streamed live from containers**
> This is basically `docker logs` but cloud-native.
### 📊 Metrics
### Per-service metrics:
- **CPU usage**
- **Memory usage**
- **Network traffic**
- **Disk usage** (for DBs)
This helps you:
- **Detect leaks**
- **Decide when to optimize**
- **Understand cost drivers**
## 🧱 Databases Inside a Project
Databases are first-class services, not addons.
When you add:
- **PostgreSQL**
- **Redis**
- **MySQL**
Railway:
- **Provisions it**
- **Injects connection URLs**
- **Handles backups** (plan-dependent)
Databases:
- **Appear on the same canvas**
- **Can be linked to multiple services**
- **Expose internal connection strings only**
### Database Benefits
- **Easy setup**
- **Managed backups**
- **Internal connection strings**
## 🌍 Environments (Prod, Preview, Dev)
Each project can have multiple environments.
### Common setup:
- **Production** live app
- **Preview** per-PR deployments
- **Development** testing
### What changes per environment:
- **Variables**
- **Domains**
- **Deployments**
- **Scaling**
> This is not separate projects — it's logical isolation inside one project.
## 👥 Project-Level Controls
At the project level (not service-level):
### 👤 Members & Permissions
- **Invite teammates**
- **Control access** (admin / developer)
### 🔔 Notifications
- **Deploy failures**
- **Usage alerts**
- **Service crashes**
### 💳 Usage & Billing
- **CPU hours**
- **RAM hours**
- **Network**
- **Cost per service**
## 🧠 How the Project Page Works Internally
Under the hood:
- **The UI talks to the Railway API**
- **Every service = container + config**
- **Every deploy = immutable container version**
- **Variables = injected at runtime**
- **Services communicate via private internal network**
> So the project page is essentially: a visual orchestrator for containers, deployments, configs, and environments
## 🧠 Mental Model (Best Way to Think About It)
If Docker Compose had:
- **A UI**
- **GitHub auto-deploys**
- **Built-in databases**
- **Metrics**
- **Logs**
- **Secrets**
- **Environments**
> 👉 That's the Railway project page.