~ knotless Search/
↑↓ move↵ open⇧↵ all results

grain.social/grain
Switch repository
Loading…

photography-focused photo sharing platform

grain.social
1 collaborator
0
2

deploy: grain-serve hands the pages every request it does not answer

Closed
Closed chadtmiller.com asked to merge into feature/rust from grain.social/grain:deploy/web
1 reviewer 1 approved
Reviewers
review.knotless.devNot a collaborator, so not counted Approved
chadtmiller.comopened

What changes

serve runs with --web http://pages:2601. Every request grain-serve does not answer itself goes to the SvelteKit app over the project's own network, so the proxy sends grain's domain to grain-serve:2600 and nothing else. The pages leave the proxy network: nothing outside the project reaches them.

deploy/README.md's Caddy snippet is one reverse_proxy grain-serve:2600, without the path split.

Why

--web landed in batch/two, but the compose file still left it off and had Caddy split paths between serve and pages. This mirrors knotless's deploy/docker-compose.yml, where knotless-serve runs with --web http://pages:2591 and its pages are on the default network alone.

It's needed now for next.grain.social: grain-serve beside the old server on grain's host, ahead of cutover. Its Caddy block in hetzner-infra is a single reverse_proxy grain-serve:2600.

How it was checked

Left to CI. The first real run is the next.grain.social deploy.

Shortcomings

None known. HOST_HEADER and PROTOCOL_HEADER stay on pages, because grain-serve sets x-forwarded-host and x-forwarded-proto when it hands a request on (pages.rs).

🤖 Generated with Claude Code

review.knotless.devreviewed Approved

This runs grain-serve with --web http://pages:2601. It drops the pages' proxy network and grain-pages alias, and it cuts the Caddy snippet to a single reverse_proxy grain-serve:2600. I checked the claims against feature/rust:

  • pages.rs does set x-forwarded-host from Host and defaults x-forwarded-proto to http, keeping any value the proxy already set. HOST_HEADER and PROTOCOL_HEADER on pages therefore still work.
  • No grain-pages reference remains outside the lines this pull edits, so nothing else depends on the removed alias.
  • The pages name resolves on the project's default network, where both services already sit.

I found nothing that needs changing. The pull relies on CI and the next.grain.social deploy as its test, so check that first deploy for the host and scheme the pages see.

chadtmiller.comcommented

Landed on feature/rust in batch/three (…/3mzbdo7hmjf2b, 236806f), with its head b901429 unchanged.