Fly.io Deployment Guide for Ticket Masala¶

Overview & Strategy: The "Sleeping Giant"¶

Ticket Masala is configured to use Fly.io's "Sleeping Giant" strategy. This allows the application to be highly performant when needed but cost-effective when idle.

Cost Structure¶

Scenario	Monthly Cost
Ideal (Demo): 5 hours/month usage	~$0.05
Light: 50 hours/month usage	~$0.50
Heavy: 24/7 running (2GB)	~$13.00

Configuration¶

The fly.toml configures:

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = true      # Stops when idle
  auto_start_machines = true     # Starts on request
  min_machines_running = 0       # Allows complete shutdown

Critical Cost Warning¶

DO NOT use external uptime monitors (UptimeRobot, Pingdom, etc.)

These services will ping your app constantly, preventing it from sleeping and causing 24/7 billing at ~$13/month. The internal Fly.io health check is configured correctly and won't prevent auto-stop.

Verifying Auto-Scale Works¶

Deploy and access your app
Wait 10 minutes without accessing it
Run fly status - should show machine stopped
Access the app again - first request takes 3-5s (cold start)
Check billing dashboard after 24-48 hours

1. Prerequisites¶

Install Fly CLI: Installation Guide
Login: fly auth login
Ensure Docker is available locally (Fly can also build remotely).

2. App Name & Region¶

Edit fly.toml if you need a different app name than ticket-masala. Choose a primary region near your users (e.g. ord, iad, fra).

3. Data Persistence (SQLite)¶

The application is configured to use SQLite in production (see Program.cs). A volume mapped to /data ensures the database is persisted across restarts.

No external SQL Server connection string is required.

4. First Launch (if not already created)¶

If you did not manually create fly.toml use fly launch in the project folder. Since we already have one:

cd IT-Project2526
fly deploy

5. Health Check¶

Program.cs maps GET /health. The Fly config defines an HTTP check hitting /health every 15s. This helps Fly decide machine health.

6. Subsequent Deploys¶

After code changes:

fly deploy

View status & logs:

fly status
fly logs

Open the app in a browser:

fly apps open

7. Scaling / Machines¶

Keep at least one machine running (min_machines_running = 1). Adjust concurrency or add regions using:

fly scale count 2
fly regions add fra

8. Common Maintenance¶

Rotate secrets: re-run fly secrets set ...
Release rollback: fly releases list then fly releases revert <version>

9. Troubleshooting¶

Symptom	Action
502 Bad Gateway	Check logs (`fly logs`); verify port 8080 exposed & `ASPNETCORE_URLS`.
DB connection failures	Ensure secret set; test via `fly ssh console`; `printenv \\| grep ConnectionStrings`.
Health check failing	Hit `https://<app>.fly.dev/health`; confirm `Program.cs` has `MapHealthChecks`.
Out of memory	Increase machine size: `fly machine update <id> --memory 1024`.

10. Database Notes¶

Fly.io volumes provide fast, persistent storage for SQLite. If you need to scale horizontally (multiple machines), you should migrate to Postgres or an external SQL Server, as SQLite does not support multiple concurrent writers across different machines easily.

11. Local Test of Image¶

(Optional) build locally before deploy:

docker build -t ticket-masala:test .
docker run -p 8080:8080 -e ASPNETCORE_ENVIRONMENT=Development ticket-masala:test

Then browse http://localhost:8080.