🚀 Deployment

Overview

LIPAIX is hosted on Railway, a cloud platform that builds and runs the apps from Git branches. Deployments are manual — nothing deploys automatically when you push to main. You trigger each deploy explicitly through GitHub Actions.

Infrastructure on Railway

The project has four services on Railway:

Service	What it runs	Deploy branch
Web	Next.js app (public site + MyLipaix + API)	deploy/web / deploy/staging/web
Discord Bot	Discord.js bot	deploy/discord-bot / deploy/staging/discord-bot
Documentation	VitePress docs	deploy/documentation / deploy/staging/documentation
PostgreSQL	Managed database	(managed by Railway, no deploy branch)

Railway watches the deploy branch for each service. When the branch changes, Railway automatically builds and re-deploys.

How to deploy

Deployments are triggered through GitHub Actions using the "Deploy to Staging/Production" workflow.

Steps

1. Go to the repository on GitHub
2. Click Actions in the top navigation
3. Find "Deploy to Staging/Production" in the left sidebar
4. Click Run workflow
5. Fill in the form:
   • App: choose Web, Discord Bot, or Documentation
   • Environment: choose staging or production
   • Branch: the branch to deploy (default: main)
   • Auto-merge: leave checked unless you want to review before deploying
6. Click the green Run workflow button

What happens

The workflow does the following:

1. Checks out the deploy branch (e.g., deploy/web)
2. Merges the chosen branch (e.g., main) into it
3. Pushes the updated deploy branch to GitHub
4. Railway detects the push and starts building

If everything merges cleanly and auto-merge is enabled, the deploy branch is updated immediately. Railway typically has the new version running within 2–5 minutes.

Conflicts

If the source branch can't be merged automatically (merge conflicts), the workflow creates a pull request instead of pushing directly. You'll need to review and merge that PR manually — once merged, Railway deploys.

This is rare if everyone works on main directly, but can happen when deploying a feature branch.

Staging vs production

The project has two environments in Railway:

Environment	URL	Deploy branch
Production	lipaix.com / admin.lipaix.com	deploy/web
Staging	staging.lipaix.com / staging-admin.lipaix.com	deploy/staging/web

Staging uses the same database structure as production but is a separate Railway environment with its own database and environment variables.

Always deploy to staging first to verify your changes before deploying to production.

Environment variables

Environment variables are managed in the Railway dashboard — not in the codebase. Each service has its own set of variables, and staging/production have separate values.

To add or change a variable:

1. Open Railway dashboard
2. Navigate to the project → the specific service → Variables
3. Add or edit the variable
4. The service will restart automatically

Never commit secrets or API keys to the repository.

Development workflow

The project uses trunk-based development: all work happens on main. There are no long-lived feature branches.

For small changes: commit directly to main.

For larger changes: create a short-lived branch, make your changes, then merge to main when ready. Delete the branch after merging.

Commit message convention

Follow the Conventional Commits format:

type: short description

Examples:
feat: add ticket prices to event cards
fix: correct venue address in Venue collection
docs: update deployment guide
chore: bump Next.js to 15.1

Common types: feat, fix, docs, chore, refactor, style.

Deploy branch naming

Deploy target	Branch
Production Web	deploy/web
Production Discord Bot	deploy/discord-bot
Production Documentation	deploy/documentation
Staging Web	deploy/staging/web
Staging Discord Bot	deploy/staging/discord-bot
Staging Documentation	deploy/staging/documentation

Never push directly to a deploy branch. Always use the GitHub Actions workflow — it handles the merge correctly and creates a PR if there are conflicts.