Documentation

On-premise

On-premise means the entire Bookmer platform runs on a server you operate. It is a Teamspace menu of its own. It is not an app, not a web package, and not a URL you paste into the developer studio.

What runs on your server

Bookmer web (Next.js) and the Bookmer API run as Node processes. Production uses npm ci, npm run build, and PM2 or systemd. Docker is not the production path. A reverse proxy (Caddy or Nginx) forwards to the host ports (default web 3000, API 6128).

PostgreSQL holds bookmarks. BK_DIR holds icons, uploads, and caches and must live outside the deploy tree.

What stays in Console

Members, permission groups, organization login, and the collection are still configured in this Console. On-premise is an Enterprise feature. Lower plans do not show the menu and cannot call these APIs. The on-premise Bookmer instance reads them from the consume API and authenticates with an install token you generate under Console → On-premise.

Console configuration

  1. Enable on-premise for the Teamspace.
  2. Set the public Bookmer URL, API URL, deploy host, user, and path.
  3. Set Postgres host/database and BK_DIR.
  4. Copy the generated backend/.env and web .env onto the server. Replace the Postgres password placeholder.
  5. Deploy with npm run deploy:selfhosted using the generated deploy variables.
  6. The instance should POST the heartbeat URL with Authorization: Bearer <install token>.

Owner API

GET   /api/developer/teamspaces/:id/on-premise
PATCH /api/developer/teamspaces/:id/on-premise
POST  /api/developer/teamspaces/:id/on-premise/token
POST  /api/developer/teamspaces/:id/on-premise/check

Workplace login

When on-premise is enabled, Console can optionally allow Windows / workplace sign-in on the organization URL only. It never appears on bookmer.com or public LoginSign. The browser cannot read a Windows ID. Your reverse proxy (IIS, Nginx, or Caddy with Kerberos/Negotiate) must send the signed-in user as X-Remote-User, Remote-User, or X-Forwarded-User. Map each member’s Windows username in Users. An authentication code is optional and stored only as a hash. How to set the code, choose the policy, and call POST /api/org/:slug/windows-login is in Authentication codes.

After workplace login is on, enable windows under Settings → Login methods. Only then does the organization login page try it. Session length is set here as hours_4, hours_8, day, or browser (until the window closes). That policy applies to the LoginSign session cookie after a successful workplace POST — not to SSO launch rows in Sessions.

Install APIs (Bearer install token)

GET  /api/org/:slug/on-premise/bootstrap
POST /api/org/:slug/on-premise/heartbeat

Bootstrap returns the consume URL and organization login. Heartbeat marks the installation connected in Console.