FastAPI + background workers qualification before choosing Railway plan
njelvaldez88
HOBBYOP
a month ago
Hi Railway team,
I’m evaluating Railway for a cybersecurity scanning SaaS and need technical confirmation before selecting a plan.
Planned architecture
- ASP.NET app/API on another host
- Python FastAPI scanner service on Railway
- Async queue workers running 24/7
- Outbound HTTPS scans to customer-owned domains
- Strict reliability and security requirements
Please answer each item with YES/NO + limit/value + plan scope (Hobby/Pro).
- ASGI/FastAPI runtime
- Is FastAPI fully supported in production with
uvicorn/gunicorn? - Any platform constraints for ASGI services?
- Is FastAPI fully supported in production with
- Background workers
- Can I run dedicated worker services 24/7 on Hobby/Pro?
- Any idle shutdown/restart behavior for workers?
- Timeouts and long-running work
- Hard request timeout limits for HTTP services?
- Recommended pattern for jobs exceeding timeout (worker queue assumed)?
- Outbound networking
- Any blocked outbound ports/protocols by default?
- Any blocked destination ranges or anti-abuse throttles that affect scanner workloads?
- Are static egress IPs available?
- Resource and scaling limits
- CPU/RAM/concurrency limits per service on Hobby and Pro?
- Replica limits and autoscaling behavior by plan?
- Persistence
- Is root filesystem ephemeral?
- Persistent volume options and limits by plan?
- Volume behavior during redeploy/rollback
- Deploy/reliability operations
- Zero-downtime deploy behavior
- Rollback support
- Health checks/readiness/liveness support
- Observability
- Log retention and access by plan
- Metrics/tracing availability by plan
- SLA / support
- Any SLA on Hobby or Pro?
- Typical support response expectations for Pro
- Data residency
- Region pinning support and constraints by plan
If helpful, I can share expected traffic profile, but this should be enough for a go/no-go decision.
Thanks!
0 Replies