You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Foresight only runs on developers' machines. The hotel's manager needs a stable address to use it, and the scheduled refreshes need a running API to call.
Goal
The backend and frontend run in production on our domain over HTTPS, and any merge to main can be deployed and rolled back.
Scope
Choose hosting for the backend and the frontend.
A production database on its own Neon branch; migrations run on every deploy before the new version starts.
Domain and HTTPS for both.
Production secrets (database URL, PredictHQ token, etc.) stored in the host, never in the repo.
Deploy from main (automatically or with one command) and a way to roll back.
A README section on how to deploy and roll back.
Considerations
The API runs background jobs in its own process and a restart kills running jobs, so the backend needs a single long-running instance: no scale-to-zero and no multiple workers.
Cost: pick something the team can keep running for the whole pilot.
Production holds real revenue data; it must not be usable without login once auth exists.
Acceptance criteria
GET /health on the production URL returns 200 over HTTPS.
The production frontend loads and calls the production API.
Following the README, a merge to main can be deployed and the previous version restored.
Activity
[-]Rates refresh by themselves and show when they were last updated[/-][+]Deploy the backend and frontend[/+]