Skip to content

fix(prod): wire MARKETING_URL + COOKIE_DOMAIN into config template#5

Merged
mastermanas805 merged 1 commit intomasterfrom
fix/prod-config-marketing-url
Apr 23, 2026
Merged

fix(prod): wire MARKETING_URL + COOKIE_DOMAIN into config template#5
mastermanas805 merged 1 commit intomasterfrom
fix/prod-config-marketing-url

Conversation

@mastermanas805
Copy link
Copy Markdown
Member

Why — three production regressions from PR #4

Step C of the OSS restructure (commit 66c8f59) removed an auto-swap
that papered over a misconfigured `APP_URL` on DO App Platform.
With the swap gone and the prod template never threading the new
`ServerConfig` fields, the live API now:

  1. `POST /webhook/new` returns `receive_url: https://instanode.dev/webhook/receive/...\`
    — the marketing host on GitHub Pages, which returns 405 on POST.
    Verified against live: `curl -X POST https://api.instanode.dev/webhook/new\` returns a broken URL.
  2. OAuth login redirects to `http://localhost:5173/dashboard.html\`
    the default for `Server.MarketingURL` kicks in because the env var
    isn't set on DO. Every new signup lands on a dead localhost URL.
  3. Dashboard upgrade button / dashboard resources response points at
    `http://localhost:5173/pricing.html\` — same cause.

Change

Add `marketing_url`, `cookie_domain`, and `allowed_origins` to
`config.prod.yaml.tpl` so envsubst populates them from DO env vars at
deploy time.

`allowed_origins` is hardcoded to the production origins (not env-driven)
because YAML-list envsubst is awkward and the prod list is stable. Change
it here if you add new frontend origins.

Deploy runbook (must do in this order)

```bash

1. (You) Rotate NEWRELIC_LICENSE_KEY in New Relic UI. Grab the new value.

Current key is sitting plaintext in DO app spec — rotate as a standalone

security fix regardless of this PR.

2. (You) Update DO env vars. Either via the UI (Apps → insta-node-lite →

Settings → App-Level Environment Variables) or doctl:

APP_ID=3fb74b82-1835-4dd1-9932-1cd49ad59cfb

Fetch current spec:

doctl apps spec get $APP_ID > /tmp/spec.current.yaml

Edit /tmp/spec.current.yaml and under services[0].envs:

- change APP_URL value to: https://api.instanode.dev

- add new entry: MARKETING_URL=https://instanode.dev (RUN_TIME, plaintext)

- add new entry: COOKIE_DOMAIN=instanode.dev (RUN_TIME, plaintext)

- replace NEWRELIC_LICENSE_KEY with the rotated value, type: SECRET

Apply:

doctl apps update $APP_ID --spec /tmp/spec.current.yaml

3. Merge this PR. DO auto-deploys on master push. Verify post-deploy:

curl -s -X POST https://api.instanode.dev/webhook/new \
-H 'Content-Type: application/json' \
-d '{"name":"verify"}' | jq .receive_url

Expected: "https://api.instanode.dev/webhook/receive/..."

(NOT the old https://instanode.dev/webhook/receive/...)

```

Test plan

Step C of the OSS restructure (66c8f59) removed the automatic
https://instanode.devhttps://api.instanode.dev swap that the
old code used to paper over a misconfigured APP_URL. With the
swap gone, the prod deploy has three regressions driven by
config.prod.yaml.tpl never threading the new fields through:

1. POST /webhook/new returns a receive_url on instanode.dev (the
   static marketing host, which 405s POST) instead of api.instanode.dev.
2. OAuth login redirects to http://localhost:5173/dashboard.html
   (the default for MarketingURL when the env var isn't set).
3. Dashboard upgrade URL points at localhost:5173 for the same reason.

This PR adds the three fields to the prod template so DO's
envsubst step populates them from env vars. The AllowedOrigins
list is hardcoded here (not env-driven) because YAML-list envsubst
is awkward and the production origins are stable.

The actual DO env var updates (APP_URL → api.instanode.dev,
new MARKETING_URL + COOKIE_DOMAIN, rotated NEWRELIC_LICENSE_KEY
as SECRET) are ops actions and must happen before this PR merges
so the first deploy after merge reads populated values. Runbook
in the PR description.
mastermanas805 added a commit that referenced this pull request Apr 23, 2026
The default for Server.MarketingURL was "http://localhost:5173" —
harmless in local dev, catastrophic in production where an operator
who hadn't configured MARKETING_URL (most of them) would have every
post-OAuth redirect land on http://localhost:5173/dashboard.html.

Dropping it to "" keeps the existing "if empty, 404 the marketing
redirects" branch active, so a misconfigured deploy fails clean
instead of silently shipping every signup to their own localhost.

The proper prod config (config.prod.yaml.tpl wiring MARKETING_URL
+ COOKIE_DOMAIN) is in PR #5. This change makes unset env vars
safe even before PR #5 lands.
@mastermanas805 mastermanas805 merged commit 1ddc2f3 into master Apr 23, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant