Overhaul: real metrics, Git integration UI, open-source hygiene, root cleanup

Backend:
- GET /services/:id/metrics with real Docker container stats
- DELETE /git/providers/:id and GET repo branches endpoint

Frontend:
- Service detail shows real telemetry or honest empty states
- Live status distinguishes idle/polling/reconnecting
- Git providers section in Settings; repo+branch pickers in Add Service
- Real logo, compact Projects header, canvas fitView fix
- index.css deduplicated (1725 -> 1384 lines)
- Fixed smoke tests, lint errors, ToastProvider/context unification

Repo hygiene:
- Added LICENSE (MIT), CONTRIBUTING.md, SECURITY.md; rewrote README
- Untracked .env.prod and data/letsencrypt secrets; fixed .gitignore
- Removed legacy root src/internal/cmd and stale configs/docs/artifacts
- Moved guides and design references under docs/

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

docs/design/inspo.md

@@ -0,0 +1,63 @@
+# 🚆 What the Railway Dashboard Is
+
+The Railway dashboard is the main web interface for managing your Railway cloud projects. It’s essentially your control panel where you can see, organize, configure, and monitor everything you’re hosting on Railway — services, deployments, databases, environments, logs, metrics, and more.
+
+You typically land on the dashboard after signing into your Railway account. It’s the central hub that gives you a high-level view of all your projects and infrastructure.
+
+## 🧠 What It Lets You Do
+
+### 📦 1. See and Manage Projects
+
+The dashboard shows all projects you own or belong to, sorted by recent activity.
+
+Each project can contain multiple services (like a web app, API, worker, database).
+
+From the dashboard you can click into each project to manage details.
+
+### ⚙️ 2. Configure and Deploy Services
+
+Within a project, you can link code repositories (GitHub) or container images.
+
+Railway handles build and deploy processes automatically — including automatic configuration for many languages/frameworks.
+
+Deployments are shown with statuses (building, deployed, errors).
+
+### 📊 3. Monitoring & Observability
+
+View logs and performance metrics (CPU, memory, network, disk usage) per service.
+
+You can create dashboards with charts and custom widgets for things like request rates or error logs.
+
+Set alerts for thresholds (like high CPU or errors) and receive notifications via Slack, Discord, email, and more.
+
+### 🔐 4. Manage Secrets & Environment Variables
+
+Set configuration variables (like API keys or database URLs) that your services use.
+
+Variables can be scoped to services or shared across the entire project.
+
+### 🔁 5. Staging & Environments
+
+Railway supports multiple environments (dev, staging, prod).
+
+You can preview changes in separate environments and promote or rollback deployments with a click.
+
+### 📚 6. Templates & One-Click Deploy
+
+Access a library of templates to quickly deploy common stacks (e.g., databases with backend, analytics tools).
+
+Templates auto-provision services and databases as a project.
+
+## 🧑‍💻 How It Works (Behind the Scenes)
+
+Railway’s dashboard directly reflects the state of your projects by talking to its API backend (the same API used by their CLI). It pulls data like:
+
+Project list and status
+
+Deployment logs and history
+
+Resources (CPU, memory, traffic)
+
+Environment and configuration values
+
+Changes you make in the dashboard (like redeploying or updating variables) are sent back to the Railway API and applied to your infrastructure.

docs/design/inspo2.md

@@ -0,0 +1,254 @@
+# 🧩 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.
+
+Key–value 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.