Deploying#

Publish a verified change to production and confirm it from the outside.

Before you start#

• npm run lint and npm test both pass. See Verifying a change.
• Your change is committed.
• Access to the Railway project that hosts the site.

How the deployment is built#

Railway builds the service with railpack, runs npm run build, and starts it with npm run start. The service is health-checked at / with a timeout of 100 seconds, restarts on failure, and gives up after 10 retries.

That means the platform's own health check exercises the same route a visitor uses. A deployment that renders an error at / will fail its health check rather than serve the error.

Deploy#

1. Confirm the working tree is clean and the verification commands have passed on the commit you intend to deploy.
2. Trigger the deployment for the midnight-marketing service.
3. Watch the build and deploy logs until the service reports healthy.

Verify#

Check production directly, not just the platform's status.

1. Request the apex and confirm it returns 200:

   Copy

   curl -sS -o /dev/null -w "%{http_code}\n" https://deployatmidnight.com/

2. Confirm the security headers survive in production:

   Copy

   curl -sSI https://deployatmidnight.com/

   Expect Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Strict-Transport-Security in the response.

3. Confirm the www hostname still redirects:

   Copy

   curl -sSI https://www.deployatmidnight.com/

   Expect 308 and a Location of https://deployatmidnight.com/.

Check both hostnames every time. A change that is only ever tested on the apex can leave the redirect broken without anyone noticing.

If it does not work#