Cloud Deployment Infrastructure#

Overview#

StudentHub's production infrastructure is split across two platforms:

• AWS EC2 — hosts the monolithic Yii2/PHP backend (studenthub) running under Apache
• Railway — hosts containerized microservices (studenthub-microservices) and the Railway-targeted build of the main PHP app

AWS EC2 — Apache/PHP Backend#

The aws-template.sh bootstrap script automates full EC2 provisioning. Key steps:

1. PHP & Apache setup: Installs PHP 7.4 and Apache2 via the ondrej/php PPA 1
2. Codebase clone: Pulls studenthub from GitHub via SSH deploy key into /var/www/html/studenthub 2
3. Application init: Runs ./init --env=Production and ./yii migrate for DB migrations 3
4. Virtual hosts: Creates separate Apache VirtualHost configs for each API subdomain 4:
   • v.studenthub.co → verification app
   • inspector.api.studenthub.co → inspector app
   • status.api.studenthub.co → status app
   • employer.api.studenthub.co → company/employer app
   • student.api.studenthub.co → candidate app
   • staff.api.studenthub.co → staff app
   • admin.api.studenthub.co → admin app
5. SSL: Enables mod_ssl, mod_rewrite, and mod_headers; each VirtualHost has both port 80 and 443 blocks 5
6. Cron: Installs the app's crontab from cron/cronlist 6

Railway Platform — Containerized Services#

Main PHP App on Railway#

The studenthub backend also ships two Railway-specific Dockerfiles for containerized deployment:

• Production: Dockerfile-nginx-railway — runs ./init --env=Production-Railway and uses nginx/railway-prod.conf
• Development: Dockerfile-nginx-dev-railway — runs ./init --env=Dev-Server-Railway and uses nginx/railway-dev.conf

Both images use PHP 8.2-FPM + Nginx and run Composer install, DB migrations, and cron on startup. The active Dockerfile is selected via the Railway environment variable RAILWAY_DOCKERFILE_PATH 7.

Railway MySQL databases are accessible via Railway CLI: railway connect mysql and railway connect mysql-wallet 8.

Microservices on Railway#

The studenthub-microservices mono-repo contains six services, each with its own Dockerfile:

Inter-service communication uses Railway's internal DNS pattern {service}.railway.internal:{port} 9. The Nginx proxy-manager routes public traffic to each internal service:

• /bawes-doc-updater/ → doc-updater.railway.internal:3003 10
• /linear/ → linear.railway.internal:3002 11
• /yeastar-voicemails/ → yeastar-voicemails.railway.internal:3001 12

The proxy-manager docker-compose.yml also mirrors this topology locally for development, using a shared microservices_network bridge 13.

AWS S3 Integration#

S3 access is handled by the S3ResourceManager component and the authentication method differs by deployment:

• EC2 (traditional): Uses AUTH_VIA_IAM_ROLE — no credentials in code 14
• Railway: Uses AUTH_VIA_KEY_AND_SECRET with credentials injected as Railway environment variables (AWS_MEDIACONVERT_RAILWAY_ACCESS_KEY_ID, AWS_MEDIACONVERT_RAILWAY_SECRET_ACCESS_KEY) 15

Production bucket: studenthub-uploads. Dev-server Railway bucket: studenthub-uploads-dev-server 16.

Sentry Error Monitoring#

Sentry is integrated via the notamedia\sentry\SentryTarget log target across all environments. Configuration strategy differs by platform:

• EC2 / traditional environments: DSN and environment label are hardcoded in the relevant environments/*/common/config/main-local.php file — see prod config 17 and dev-server config 18
• Railway environments: DSN and settings are injected via environment variables SENTRY_DSN, SENTRY_ENVIRONMENT, and SENTRY_TRACES_SAMPLE_RATE 19

Architecture Diagram#

Key Files & References#