@sneak these are the parts of putting dnswatcher on fsn1app1 that need your access or your call. The repo-side work is tracked separately and does not wait on this.
Decision: which branch does upaas deploy from?
#78 (closed) planned a prod branch fed by periodic main to prod PRs. Since then this repo gained next, so main already only ever receives a reviewed milestone that you merged yourself.
Deploy from main. Your merge of the milestone PR is the deploy. No third branch.
Deploy from prod. One more PR per deploy; lets main run ahead of production.
Recommendation: option 1. main is already gated by you, and a third branch adds a step without adding a check. The README deploy section will say main unless you say otherwise.
Needs your access
Create the upaas app on fsn1app1: repo URL, deploy key, webhook, branch as decided above.
Volume: a host directory mounted at /var/lib/dnswatcher.
Environment: DNSWATCHER_TARGETS (the real list of domains and hostnames you want watched), and the notification endpoints (DNSWATCHER_SLACK_WEBHOOK, DNSWATCHER_MATTERMOST_WEBHOOK, DNSWATCHER_NTFY_TOPIC), plus DNSWATCHER_METRICS_USERNAME / DNSWATCHER_METRICS_PASSWORD if you want /metrics.
Whether the dashboard is exposed publicly. It is unauthenticated by design and shows every watched name and recent alert.
What should be on main before the first deploy
The two notification types that cannot fire today (#104, #105) and the security headers (#98). It runs fine without them; it just watches less than the README says.
Model: fable-5-1
@sneak these are the parts of putting dnswatcher on `fsn1app1` that need your access or your call. The repo-side work is tracked separately and does not wait on this.
## Decision: which branch does upaas deploy from?
https://git.eeqj.de/sneak/dnswatcher/issues/78 (closed) planned a `prod` branch fed by periodic `main` to `prod` PRs. Since then this repo gained `next`, so `main` already only ever receives a reviewed milestone that you merged yourself.
1. **Deploy from `main`.** Your merge of the milestone PR is the deploy. No third branch.
2. **Deploy from `prod`.** One more PR per deploy; lets `main` run ahead of production.
Recommendation: option 1. `main` is already gated by you, and a third branch adds a step without adding a check. The README deploy section will say `main` unless you say otherwise.
## Needs your access
- Create the upaas app on `fsn1app1`: repo URL, deploy key, webhook, branch as decided above.
- Volume: a host directory mounted at `/var/lib/dnswatcher`.
- Environment: `DNSWATCHER_TARGETS` (the real list of domains and hostnames you want watched), and the notification endpoints (`DNSWATCHER_SLACK_WEBHOOK`, `DNSWATCHER_MATTERMOST_WEBHOOK`, `DNSWATCHER_NTFY_TOPIC`), plus `DNSWATCHER_METRICS_USERNAME` / `DNSWATCHER_METRICS_PASSWORD` if you want `/metrics`.
- Whether the dashboard is exposed publicly. It is unauthenticated by design and shows every watched name and recent alert.
## What should be on `main` before the first deploy
The two notification types that cannot fire today (https://git.eeqj.de/sneak/dnswatcher/issues/104, https://git.eeqj.de/sneak/dnswatcher/issues/105) and the security headers (https://git.eeqj.de/sneak/dnswatcher/issues/98). It runs fine without them; it just watches less than the README says.
Model: fable-5-1
clawbot
added this to the 1.0 milestone 2026-09-21 09:18:32 +02:00
sneak
was assigned by clawbot2026-09-21 09:18:32 +02:00
The deploy-branch question here is settled by sneak's standing ruling of 2026-08-30: upaas deploys each app from a prod branch cut from main, so releases stay independent of what the instances run, and a merged main to prod PR is a deploy. Creating prod and the repo-side readiness are ours, queued for when dnswatcher resumes (paused under the current priority rule). What stays with sneak here is only the setup on fsn1app1 once upaas runs there (sneak/upaas#181).
Model: opus-5-5
The deploy-branch question here is settled by sneak's standing ruling of 2026-08-30: upaas deploys each app from a `prod` branch cut from `main`, so releases stay independent of what the instances run, and a merged `main` to `prod` PR is a deploy. Creating `prod` and the repo-side readiness are ours, queued for when dnswatcher resumes (paused under the current priority rule). What stays with sneak here is only the setup on fsn1app1 once upaas runs there (https://git.eeqj.de/sneak/upaas/issues/181).
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
@sneak these are the parts of putting dnswatcher on
fsn1app1that need your access or your call. The repo-side work is tracked separately and does not wait on this.Decision: which branch does upaas deploy from?
#78 (closed) planned a
prodbranch fed by periodicmaintoprodPRs. Since then this repo gainednext, somainalready only ever receives a reviewed milestone that you merged yourself.main. Your merge of the milestone PR is the deploy. No third branch.prod. One more PR per deploy; letsmainrun ahead of production.Recommendation: option 1.
mainis already gated by you, and a third branch adds a step without adding a check. The README deploy section will saymainunless you say otherwise.Needs your access
fsn1app1: repo URL, deploy key, webhook, branch as decided above./var/lib/dnswatcher.DNSWATCHER_TARGETS(the real list of domains and hostnames you want watched), and the notification endpoints (DNSWATCHER_SLACK_WEBHOOK,DNSWATCHER_MATTERMOST_WEBHOOK,DNSWATCHER_NTFY_TOPIC), plusDNSWATCHER_METRICS_USERNAME/DNSWATCHER_METRICS_PASSWORDif you want/metrics.What should be on
mainbefore the first deployThe two notification types that cannot fire today (#104, #105) and the security headers (#98). It runs fine without them; it just watches less than the README says.
Model: fable-5-1
clawbot referenced this issue2026-09-21 10:01:02 +02:00
The deploy-branch question here is settled by sneak's standing ruling of 2026-08-30: upaas deploys each app from a
prodbranch cut frommain, so releases stay independent of what the instances run, and a mergedmaintoprodPR is a deploy. Creatingprodand the repo-side readiness are ours, queued for when dnswatcher resumes (paused under the current priority rule). What stays with sneak here is only the setup on fsn1app1 once upaas runs there (sneak/upaas#181).Model: opus-5-5