Files
beardrive/web/docs
fb6ce347c4 feat(daemon): survive a reboot — login autostart on macOS/Linux/Windows, and a lock instead of a pidfile (#88)
* feat(daemon): bring sync back after a reboot, and stop trusting the pidfile

A reboot killed every daemon and nothing restarted them. Agent hooks still
synced per turn, which is what made it easy to miss: a folder looked fine
while an agent worked in it and went stale the moment one didn't. `bdrive
init` now registers a login item (macOS: a user LaunchAgent) that runs the
new `bdrive resume` — one registration per machine, which starts a daemon for
every enrolled, unpaused mount, so adding a project later needs no
re-registration and `bdrive stop` still means stay stopped. `--no-autostart`
opts out, `bdrive autostart install|uninstall` manages it.

Writing the plist is the whole job: no `launchctl` shell-out. launchd loads
agents at login anyway, the caller has just started the daemon for this
session, and shelling out would let a test or a packaging script register a
real login item as a side effect.

The recovery path was also broken, which is why this is one change. Liveness
came from `kill(pid, 0)` on daemon.pid — but that file lives in
$BDRIVE_HOME and survives the reboot that killed its process, so any
same-user process recycling the pid read as a live daemon. `bdrive status`
said "running", and worse `daemon.Start` returned early, so the one
documented recovery (`bdrive init`) reported success and started nothing.
Liveness is now an flock held for the daemon's lifetime: the kernel drops it
at death or reboot, and it makes two daemons on one mount impossible. The pid
stays for display and for signalling.

internal/autostart is darwin-only today; autostart_other.go returns
ErrUnsupported and every caller already treats that as "nothing to do", so
Linux (systemd user unit) and Windows are one file each.

Tests: internal/daemon gets its first ones — a recycled pid must not read as
running (the exact regression), the lock decides liveness, a second holder is
refused. internal/autostart covers write/idempotency/stale-path-rewrite/
uninstall with HOME redirected, and lints the plist with plutil so launchd
can actually parse it. The CLI e2e asserts init registers the agent, that it
runs `resume`, that resume finds the live daemon instead of starting a
second, and that --no-autostart is silent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016aYntCWwdUhpzUfEk3ddyJ

* feat(autostart): Linux support — a systemd user unit alongside the launchd agent

Same three functions, same discipline. Linux writes
$XDG_CONFIG_HOME/systemd/user/beardrive.service (Type=oneshot, no Restart= —
`bdrive resume` exits by design) plus the default.target.wants symlink that
`systemctl --user enable` would create, because systemd ignores a unit
nothing wants. No `systemctl` shell-out, for the same reasons as launchctl:
the file is the registration, it only matters at the next login, and a
container or ssh session has no session bus to talk to.

Install declines with ErrUnsupported unless systemd is actually the init
system (/run/systemd/system, i.e. sd_booted) — on Alpine, WSL1 or a slim
container a unit file is inert decoration, and reporting "registered" would
be a lie. Installed() likewise requires the enable symlink, not just the
unit: a unit nothing wants never starts.

os.UserConfigDir honors XDG_CONFIG_HOME, so relocated config dirs work.
Windows is now the only gap; autostart_other.go is !darwin && !linux, and the
shared writeIfDifferent/selfPath moved into the tag-free autostart.go (darwin
now uses them too).

Tests run on Linux, not just compiled for it: cross-compiled test binaries
executed in a container, both with /run/systemd/system present (unit written,
enabled, idempotent, stale ExecStart rewritten, broken symlink repaired,
XDG honored, uninstall removes both) and without it (Install declines and
writes nothing). The daemon flock tests were run there too, since flock
semantics are per-OS.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016aYntCWwdUhpzUfEk3ddyJ

* feat(autostart): Windows support — a per-user Run entry

Third platform, same three functions. Windows has no user service manager in
the launchd/systemd sense, so the registration is a HKCU\...\Run value via
golang.org/x/sys/windows/registry (already in the module graph; go mod tidy
just promotes it to direct).

Chosen over the alternatives for the same reason the other two write files:
no admin rights, no COM (a Startup-folder .lnk needs it), no schtasks
shell-out. It is also honestly discoverable — the entry appears in Task
Manager's Startup tab, where someone can disable it without knowing bdrive
exists. The executable is quoted because Explorer parses the value as a
command line and Program Files has a space in it.

Two things a reader should not have to discover for themselves:

- The tests here have NEVER RUN. They are written and compile-checked
  (GOOS=windows go test -c) from macOS; there is no Windows host or usable
  container on an arm64 mac. They execute the first time the suite runs on
  Windows. They also cannot use a temp HOME the way the macOS and Linux tests
  do — HKCU is real — so each one snapshots and restores the previous value.
- `GOOS=windows go build ./...` still does not pass, and this package is not
  why: internal/store's Lock uses syscall.Flock and internal/daemon uses
  syscall.Kill and Setsid, all unix-only (true before this branch too). A
  Windows port means LockFileEx plus a stop story for a platform with no
  SIGTERM — a separate change, against the sync invariants, and untestable
  from here. So this code is correct and currently unreachable.

autostart_other.go is now !darwin && !linux && !windows (the BSDs).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016aYntCWwdUhpzUfEk3ddyJ

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 13:32:13 +09:00
..

docs.beardrive.ai

The public product documentation: CLI, sync model, self-hosting. Astro + Starlight, static output, Pagefind search.

npm install
npm run dev       # http://localhost:4321
npm run build     # -> dist/
npm run preview

Why this is a standalone site

Unlike the hub frontend (internal/webapp/static) and the cloud landing page (cloud/internal/landing/dist), this is not embedded into a Go binary:

  • Docs change far more often than the binary. Embedding them would mean a Go rebuild and redeploy to fix a typo.
  • A Pagefind search index has no business shipping inside every self-hoster's install.

It lives in the OSS repo because that is what it documents. "Edit this page" resolves to something an outside contributor can open a PR against.

Design tokens

scripts/tokens.mjs reads the @theme block in internal/webapp/frontend/src/tw.css — the source of truth for the BearDrive palette — and emits src/styles/tokens.gen.css. That file is generated, gitignored, and regenerated by npm run dev and npm run build, so the palette cannot drift. src/styles/custom.css maps Starlight's --sl-color-* variables onto it and invents no colors of its own.

(The cloud landing page can't do this — it sits in a different Go module and keeps a copy of the tokens, policed by its own check-tokens.mjs.)

Adding a page

Drop a .md file under src/content/docs/<section>/ with title and description frontmatter, then add its slug to the sidebar in astro.config.mjs. Sidebar order is explicit, not alphabetical.

Write description for every page: it is the meta description, the search result snippet, and what llms.txt shows.

llms.txt

starlight-llms-txt generates /llms.txt, /llms-small.txt, and /llms-full.txt at build time.

Convention puts llms.txt at the root domain, not a docs subdomain — so beardrive.ai/llms.txt should redirect or proxy to docs.beardrive.ai/llms.txt. That redirect lives in the cloud landing page and is the one cross-repo coordination point this split introduces.

Structure

The sidebar order in astro.config.mjs is the recommended path, and the recommended path is agent-first:

  • Start here — what it is, set up with your agent, first hour. No brew install appears in this group.
  • Working with agents — the workflows the product exists for.
  • Manual setup (optional) — the CLI route: install, set up by hand, skills and hooks in detail. Same destination, more steps; one click away, never on the critical path.
  • Use cases — job-shaped titles ("Share work across your team's agents"), persona named in the first line and in the description. These pages ROUTE: who it's for, what you get, the one setup difference, links out. The moment one starts teaching a feature, it links to the guide that owns it instead.
  • Self-hosting, Reference, Concepts — unchanged in intent.

Keep new onboarding content out of Manual. If a page teaches someone how to get started, it belongs in Start here and should say what to ask an agent, not what to type.

Deploying

Static output in dist/. Any static host works; build command npm run build, output directory dist, project root web/docs.

Redirects

The docs were reorganized around the agent-first path, so three old URLs moved:

Old New
/start/install /manual/install/
/start/quickstart /manual/setup-by-hand/
/guides/connect-an-agent /start/setup/

astro.config.mjs declares these, which in a static build emits meta-refresh pages — fine for humans, weak for search engines. Real 301s belong in the host.

Firebase Hosting (simplest static option on GCP — CDN, TLS, and custom domains included):

{
  "hosting": {
    "public": "dist",
    "ignore": ["firebase.json", "**/.*"],
    "redirects": [
      { "source": "/start/install", "destination": "/manual/install/", "type": 301 },
      { "source": "/start/quickstart", "destination": "/manual/setup-by-hand/", "type": 301 },
      { "source": "/guides/connect-an-agent", "destination": "/start/setup/", "type": 301 }
    ]
  }
}

Cloud Storage behind an external Application Load Balancer: put the rules in the URL map, which redirects before the bucket is ever reached.

gcloud compute url-maps edit docs-url-map   # pathMatchers[].pathRules[]:
#   - paths: ["/start/install"]
#     urlRedirect:
#       pathRedirect: "/manual/install/"
#       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
#       stripQuery: false

Whichever host wins, keep the Astro redirects block as well: it is the portable fallback, and it keeps local npm run preview honest.

Note that the build reads a file outside web/docs (the token source), so the host must check out the whole repository rather than just this subdirectory.