Security

Sightline holds keys that can change real work in real organisations. This is how it keeps them, stated as plainly as the code allows.

• Keys you paste are sealed under a key of your own

  Every credential the console uses is sealed with AES-256-GCM under a data key that belongs to your account alone, and that data key is itself stored only in encrypted form under a master key held outside the database. A copy of the database on its own opens nothing.

• A key is never sent back to a browser

  Once saved, a key stays on the server. The settings screen receives a masked value that shows at most the last four characters, enough to recognise a mis-pasted key and nothing more. Writes to your tools look the key up on the server and never serialise it.

• A connection that stops working says so

  Every refresh records whether each Linear workspace and, if connected, your calendars and GitHub actually answered, and every connection test records the same, Slack included. Settings shows beside each connection when it last worked and its last error, so a revoked or expired key shows up as a named failure rather than a quiet, empty board.

• Writes go through an allowlist

  A change you make from the console is one of four kinds in Linear or four in your calendar; any other action is refused before a request is sent, Linear ids and dates are validated before a Linear write, and dates, times and durations before a calendar booking. In your calendar the console moves, completes or deletes only events it created itself, and once you list the calendars Sightline may use, it refuses to write to any other.

• Row-level security is a second lock

  Behind the application’s own account checks, Postgres itself fences your keys, connections, settings and dashboard data: every one of those tables has row-level security forced on, and the app’s database role can read and write only the rows of the account it is acting for.

• You can run it yourself

  Sightline can be self-hosted as a single-operator deployment in your own Vercel project with your own Neon database, signed in with a password rather than hosted accounts. Say so in your request.

Not here yet

• Roadmap: shared organisations and per-member state
• Roadmap: one-click OAuth connections — today you paste a key
• Roadmap: self-serve plans — today access is granted by hand
• Roadmap: a hosted morning digest in Slack for each account — today the digest runs only for the operator