v2.4.1

Follow-up to 2.4.0's security hardening: a trusted proxy list, a bounded rate limiter, and tests that
were checked to fail when the protection they cover is removed.

Security

• The in-memory rate limiter stays bounded under a flood of distinct clients. Before, once
  200,000 counters were all still running, every request rescanned the whole map (CPU) and new
  clients kept being added (memory). Now it sweeps at most once a second and, while full, doesn't
  track new clients (those already counted stay limited). Found by a test that hung.
• trustedProxy.peers: the addresses (IPs or CIDR ranges) of the proxies allowed to set the
  forwarded-address headers. When it is set, a request from any other address has its headers
  ignored, so a client can't forge its address to dodge rate limits and lockouts; trusted hops are
  skipped from the right. Health warns when headers are trusted but no peers are listed.
• Tests that can fail: the SQL console test expected a 403, which a console that is switched off
  also returns, so it would have passed with the role check removed; it now runs with the console on
  and fails without the check. Backup retries and the file swap of a restore (the old files must
  stay if it fails) are tested too.

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.4.1
• Debian/Ubuntu: slonbase_2.4.1_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.4.1-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.4.1-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.

v2.4.0

Security hardening: safer defaults, checks that say when a setup is weak, and tests that hold
every path to the same rules. Prompted by an outside review of the code.

Upgrading

• The sign-in lockout is now on, everywhere: 10 failed password sign-ins per identity and
  address in 15 minutes. Installations that had it at 0 (the old default) are switched on once,
  at the first start of 2.4; turn it off again in Settings, Security, if you really need to
  (Health will warn).

Security

• Rate limits keep their total when the database fails. With several instances, requests are
  counted in PostgreSQL; if that failed, each instance counted on its own, so three instances
  allowed three times the limit, and only a debug log said so. Now each instance counts its
  share of each limit (the limit divided by the live instances), the failure is logged as a
  warning, and Health reports it.
• Health has security checks: slonbase connecting as a PostgreSQL superuser, the lockout
  off, rate limits off or recently degraded, and an application URL without https.
• The SQL console can run as a role of its own: --sql-console-role
  (SLONBASE_SQL_CONSOLE_ROLE, server.sql_console_role) runs its statements with
  SET LOCAL ROLE, so it can have fewer privileges than slonbase, such as read-only access
  (see configuration).
• One test for every way to reach a record: tests/authz_matrix.rs checks that list, view,
  counts, filters (through relations and @collection), forward and back expand, protected
  files, realtime, update, delete and batch all agree with the same rules, for a guest and two
  users.
• Generated filter tests: thousands of filters full of SQL and filter metacharacters are
  compiled, checking that a client's value never reaches the SQL text, only parameters, and
  20,000 random inputs that the parser and compiler never panic.
• A restricted dashboard role could reach what it forbids by another route (reported by two
  outside reviews, reproduced with tests before fixing; see the
  security reviews). A developer could create a superuser (which
  starts as an owner) through the superusers collection's id or through a batch; a read-only
  API key could change its owner's password; an import could carry the superusers
  collection; the SQL console was open to developers and admins, and reads every table.
  Roles now apply to a collection however it is addressed, to every request in a batch and an
  import, API keys can't change the account they belong to, and the SQL console is for owners.
• Backups extract within the free disk space and a limit of entries, and a failed automatic
  backup is retried; a restore stages the files before the database changes; CI runs on pull
  requests and fails, rather than skips, without its database.
• A threat model: what slonbase protects and trusts, how each boundary is
  enforced and tested, and how to check a deployment. SECURITY.md invites independent review.

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.4.0
• Debian/Ubuntu: slonbase_2.4.0_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.4.0-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.4.0-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.

v2.3.1

slonbase is now licensed under the Apache License 2.0.

Changed

• License: Apache 2.0 (was MIT) for everything released from this version on, with an
  explicit patent grant. Versions up to and including 2.3.0 were released under MIT and remain
  available under it. The dependencies are all under permissive licenses. See
  license and contributing terms.
• Contributions need a signed CLA: a bot asks on a first pull request. Contributors
  keep their copyright; the agreement licenses their work under Apache 2.0 and lets the
  maintainer license it under other terms in future. Everything released under Apache 2.0 stays
  under it; the maintainer may one day offer separately licensed commercial features or hosted
  services, which the CLA makes possible.

Added

• NOTICE (third-party notices), a trademark policy for the name and
  logo, a license guide, and the license named in the package metadata, the
  README, the site, llms.txt and the structured data.

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.3.1
• Debian/Ubuntu: slonbase_2.3.1_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.3.1-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.3.1-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.

v2.3.0

Several instances, tested properly. Running slonbase as a fleet, behind a balancer, behind
PgBouncer and with projects on other servers, was run for real (scripts/fleet-test, also in CI),
which found problems that are fixed here, and a scaling guide now says what
works, what was measured and where the limits are.

Added

• database.listen_url (--database-listen-url, SLONBASE_DATABASE_LISTEN_URL): a direct
  connection for LISTEN/NOTIFY, so slonbase works behind PgBouncer in transaction mode. Without
  it, behind such a pooler, instances started and answered requests but stopped sharing schema
  changes, settings, realtime events and rate limits, with no error.
• Health checks for a fleet: sync (each instance sends itself a notification every minute
  and shows an error, naming a transaction-mode pooler and the fix, if it doesn't arrive) and
  connections (PostgreSQL's connections in use against its limit, a warning from 80% and an
  error from 95%, since several instances and projects multiply them).
• Sign out everywhere: POST /api/collections/{collection}/records/{id}/revoke-tokens gives a
  record a new token key, so every token it holds stops working on every instance; a user may
  call it for themselves, a superuser for anyone. The dashboard's record menu has the action.
  (Tokens are stateless, so there is no per-device logout, as in PocketBase.)
• Scaling and deployment topologies: five layouts with diagrams (one
  instance; projects on several servers; a load balancer; PgBouncer; managed failover), the
  connection budget N × (18 + 5 × projects) with measured numbers, what is shared and what is per
  instance, sessions and sign-out across instances, upgrades, nginx, HAProxy and PgBouncer
  recipes, and the limits.
• scripts/fleet-test: several instances behind a balancer with no affinity, checking tokens,
  schema and settings propagation, shared rate limits, realtime forwarding and projects, run in
  CI directly and through PgBouncer.

Changed

• Idle project pools release their connections after two minutes, so many projects don't each
  hold a few connections for nothing.
• Pooler-safe session state: the backup lock is a transaction lock on a dedicated connection,
  and the SQL console's and JavaScript hooks' SETs are SET LOCAL inside a transaction, so
  nothing leaks onto the next user of a pooled connection (a leak that was possible even without a
  pooler).
• A realtime subscribe request that was forwarded to an instance that has died answers after two
  seconds instead of five.
• The website's scale-out section and the documentation say what was tested, including the
  limits (connections, local files, no rolling upgrades).

Website, documentation and discovery

Added

• Easier to find, for search engines and for AI assistants: a sitemap, a robots.txt that
  welcomes search and AI crawlers, canonical addresses and Open Graph cards on every page,
  structured data (software, FAQ, breadcrumbs, articles), a 404 page, llms.txt and
  llms-full.txt with every guide also served as Markdown (/docs/<page>.md), and an IndexNow
  ping on each deploy.
• New guides: About, Features, a five-minute
  quickstart, slonbase and PocketBase,
  slonbase vs PostgREST and the benchmarks.

Changed

• slonbase is described as what it is now: a backend platform on PostgreSQL (many projects,
  roles and API keys, an SQL console, designers, scale-out), compatible with the PocketBase SDKs,
  not "PocketBase's API on PostgreSQL". The README, the site, the package descriptions and the
  documentation lead with that.

• The documentation site uses the dashboard's colours, and passes the accessibility checks.

• A new look for https://slonbase.com, built from the dashboard's own colours, type and
  components, with a screencast of the real dashboard, every dashboard screen (the command
  center for projects, the SQL console, settings and the email designer included) and the
  benchmark numbers of 2.2.

• Benchmarks of 2.2.0 against PocketBase 0.40.6 and PostgREST 16.5, with memory, binary size
  and start-up time (bench/; the runs are kept in bench/published/2.2.0). The binary is 22 MB
  on disk (10 MB to download), not the 8 MB the page said.

• The dashboard screenshots are taken, and the tour recorded, by scripts/demo/run.sh, from a
  seeded demo installation.

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.3.0
• Debian/Ubuntu: slonbase_2.3.0_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.3.0-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.3.0-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.

v2.2.0

slonbase.com, and an installation that starts from a bare server.

Added

• install.sh: curl -fsSL https://slonbase.com/install.sh | sudo sh takes a Debian,
  Ubuntu, Fedora, RHEL, Rocky or Alma server to a working instance: it installs PostgreSQL when
  there is none (a 14 or newer; on RHEL 8 and 9 it enables the 16 stream and moves localhost
  logins from ident to passwords), creates a role and a database for slonbase with a generated
  password (never touching an existing role or database), adds the signed repository, installs
  the package and creates the first superuser. It prints each step and the sign-in at the end,
  takes its choices from environment variables (SLONBASE_EMAIL, SLONBASE_DATABASE_URL, ...)
  and is safe to run again. It is checked with ShellCheck in CI.
• A guide from zero: the installation guide starts with that command, then does each step by
  hand (PostgreSQL, the role and database, the package, the setup), and ends with a check that
  it works and a troubleshooting table. Docker and Docker Compose are their own sections.

Changed

• The project lives at https://slonbase.com (the apt and dnf repositories, the docs and the
  page). Old github.io addresses redirect, so existing repository entries keep working.
• The documentation, README, site and every dashboard screenshot are brought up to date with the
  current release (the screenshots were from 2.0, before the layered surfaces); the package's
  post-install message says that a database is needed and points at the installer.

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.2.0
• Debian/Ubuntu: slonbase_2.2.0_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.2.0-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.2.0-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.

v2.1.3

A leaner release pipeline. The same binary as 2.1.2; only how it is built and published
changed.

Changed

• The apt and dnf repositories keep the five newest versions. They carried every release,
  and their GitHub Pages deployment grew past the 1 GB limit, so publishing 2.1.2 to them
  timed out. Older versions stay on their release pages
  as .deb, .rpm and .tar.gz files and as Docker images.
• Releases build their packages once, and update the repositories once. CI no longer builds the
  packages or the image from source on every push (the release does, before it publishes), and
  its jobs that run slonbase share a single build.

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.1.3
• Debian/Ubuntu: slonbase_2.1.3_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.1.3-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.1.3-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.

v2.1.2

A dashboard whose parts you can tell apart.

Changed

• Layered surfaces. The light theme's page is a soft grey with white cards, inputs and
  tables on it, and darker wells (table heads, code) in them; the sidebar is a step darker than
  the page; cards have a faint shadow. In the dark theme the cards and inputs are lighter than
  the page, and table heads lighter again. Before, the page and the cards were the same white
  (or the same black) and only hairlines told them apart.
• Controls follow the accent. Checkboxes, radio buttons and sliders take the installation's
  accent (they were always the browser's colour), as does the endpoint's method label.
  Status colours stay green, amber and red whatever the accent.
• Settings → Mail: the preview is below the editor, as wide as it, instead of beside it in
  half the width.
• The overview's collections scroll inside their card (with a filter once there are more
  than ten) instead of making the page as long as the list.

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.1.2
• Debian/Ubuntu: slonbase_2.1.2_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.1.2-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.1.2-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.

v2.1.1

A dashboard that stays usable during bulk imports, and honest about logging.

Fixed

• A bulk import made the dashboard laggy. A batch holds a database connection for its whole
  transaction, and a project's pool is small (4 by default), so a few import workers took every
  connection and the dashboard's own requests waited behind them. Batches and uploads now take
  turns, using all but one connection of the pool; the rest wait, instead of failing on the
  pool's timeout, and one connection is always free for everything else.
• The overview showed a confident low request count when request logging was off. Requests
  are counted from the request logs, so with logging off (logs.maxDays of 0, as an import
  script may set) it counted nothing. The overview now says "Not logged" and links to the
  setting, Health warns, and the command center shows "No logs" on the installation.
• Settings → Application had two save buttons for the accent: its own, and the settings
  bar's. The accent is saved with the bar, like everything else; Reset preview stays.
• App users → New auth collection opened the dialog with the Base type. It starts with
  Auth now.

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.1.1
• Debian/Ubuntu: slonbase_2.1.1_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.1.1-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.1.1-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.

v2.1.0

The rest of 2.0's plan: files, sign-in protection and a rate-limit tester.

Added

• Lockout after failed sign-ins (security.loginLockout): an identity that fails
  attempts password sign-ins from one address within minutes gets 429 until the window
  ends, even with the right password; a success clears the count. Shared by every instance.
  Off by default.
• The interval between auth emails is a setting (security.authEmailInterval, 60 seconds
  by default, 5 to 86,400): verification, password reset, email change and one-time
  passwords, per account.
• Files: files.defaultMaxSize sets the largest file for file fields without a size of
  their own (it was always 5 MB), and files.thumbs turns thumbnails off (the original file
  is served instead). Settings → File storage shows both, and each auth collection's session
  and protected-file token lifetimes; Team shows the superusers'.
• A rate-limit tester: Settings → Security & limits says which rule a request would meet
  (POST /api/settings/rate-limits/explain), with the same matcher the guard uses.

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.1.0
• Debian/Ubuntu: slonbase_2.1.0_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.1.0-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.1.0-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.

v2.0.0

Settings in which every setting does something. The Settings page is rebuilt: an
appearance with named accents, the application's name and images used everywhere, a sign-in
page of your own, an email designer, roles for superusers and API keys, a history of what
backups and cron jobs did, CORS, maintenance, and more of logs, storage and import. Each
installation (the main one and every project) has its own.

Upgrading

Nothing needs doing: existing settings and superusers carry over. What behaves differently:

• The API sends CORS headers, allowing pages on any site, as PocketBase does; slonbase sent
  none before, so browsers refused cross-origin calls. To allow only some sites, list them in
  Settings → Security & limits (security.allowedOrigins).
• Emails are put in a layout (the logo, a card, the application's name and address), unless
  a template is a whole HTML document of its own. Turn it off, or change it, in Settings → Mail
  (mailLayout.enabled).
• Every superuser is an owner until you give them another role, so nobody loses access.
• Two migrations add _slonbase.assets (images, included in backups) and
  _slonbase.job_runs (the jobs' history). A backup made with 2.0 can't be restored by 1.x.
• GET /api/crons items have more fields (description, next, kind, lastRun);
  GET /api/backups items have encrypted and auto.
• The default accent is sage (the colour the dashboard already had); saved colours stay.
• For the Rust library API: RequestAuth has a role field, and logs::cleanup takes the
  maximum number of entries.

Added

• Settings, reorganized. Sections are grouped (Workspace, Delivery, Operations,
  Protection, Data), with a dot on those with unsaved changes. Links to a section (from Health's
  checks, the command palette) keep working.

• Appearance. Settings → Application has cards for the color mode (system, light, dark;
  kept per browser) and thirteen named accents (Sage, Slate, Mauve, Clay, Sand, Teal, Ocean,
  Indigo, Rose, Forest, Amber, Plum, Graphite), each with a light and a dark tone that stay
  readable (WCAG AA) in either theme, or a color of your own, with a preview to try them before
  saving. The accent is the installation's: it applies before the first paint, on the sign-in
  page too, and each project has its own.

• The application's name means something. It names the browser tab (Logs · Acme), the
  sidebar and the sign-in page, besides emails.

• Branding: images and logos. Each installation keeps a library of images (PNG, JPEG,
  WebP, GIF, ICO or SVG, up to 2 MB, up to 100) at /api/branding/assets, and chooses its logo,
  its logo on dark backgrounds and its browser icon from it. Anyone may view an image (the
  sign-in page and emails show them); only superusers upload, rename or delete them, and an
  image the settings use can't be deleted. They live in the database, so they go with backups.

• A sign-in page of your own. Settings → Login screen sets its layout (beside the code
  panel, in a card, or alone), background (plain, a grid or an image), heading, line under it,
  logo, a notice (plain text), up to three links (https: or mailto:) and whether
  "powered by slonbase" shows, with a live preview of the real page.

• A history of what ran. Automatic and manual backups and cron jobs (hooks' cronAdd and
  the backups' schedule) record each run: when, what started it, how long it took, how it
  ended (with the error when it failed) and, for backups, the file, its size and whether it's
  encrypted. The last 500 runs of each job are kept (GET /api/jobs/runs).

• Backups say whether they're encrypted (encrypted, from the file's first bytes, in
  GET /api/backups) and whether they're automatic; the page filters them and shows when the
  next automatic one runs.

• Cron jobs, at a glance: each job's schedule in words ("every day at 03:00"), its next run
  and how its last run went (GET /api/crons has description, next and lastRun), with
  its history.

• File storage shows where files are: the directory on the server (or the bucket), the free
  space there, what the uploads take (measured in the background, by collection) and
  thumbnails, which can be cleared (GET /api/settings/storage).

• CORS. Pages on other sites may call the API, as with PocketBase; Settings → Security &
  limits can restrict that to some origins (security.allowedOrigins). Until now, slonbase
  sent no CORS headers, so browsers refused such calls.

• More of Security & limits: maintenance (the API answers 503 with your message to all but
  superusers and health checks), HTTPS only (Strict-Transport-Security, when the application
  URL is https), and the largest request (128 MB by default, now a setting).

• More of Logs: paths not to log (unless they fail on the server), slow requests logged as
  warnings whatever the minimum level, and a maximum number of entries.

• Import & export: choose which collections to export (system ones too, indented or not, to
  copy or download); an import shows, collection by collection, the fields added, changed and
  removed, the rules and indexes it changes, and what Replace would delete; and the settings
  can be exported and applied elsewhere (without passwords, secrets or images).

• An email designer. Settings → Mail edits the layout around every email and each auth
  collection's messages (verification, password reset, email change, one-time password, new
  sign-in alert) as HTML, with buttons to insert placeholders, a live preview of what the
  server would send (desktop or phone width, in a sandboxed frame that runs nothing), and a
  test send from the collection's own template (the dashboard used to always send the
  superusers').

• A layout around every email (mailLayout, on by default): the logo, a card in the
  accent's color, the application's name and address. A template that's a whole HTML
  document of its own isn't wrapped.

• New placeholders in emails: {APP_LOGO} (the logo, or the application's name),
  {APP_LOGO_URL}, {ACCENT} and {RECORD:field} (the recipient's fields, escaped; hidden
  fields, the password and the token key stay empty). POST /api/settings/mail/preview
  renders an email with sample values.

• Roles for superusers. Each superuser of an installation is an owner (everything, as
  before), an admin (everything but the team, restores and deleting projects), a developer
  (collections, records, files, the SQL console when it only reads, cron jobs) or a viewer
  (looks at everything but backups' files, changes nothing). Roles are checked for every
  request, extensions' routes included; everyone may still sign in, refresh their session and
  change their own password. There's always an owner. Settings → Team lists the superusers,
  adds them and changes their roles (GET /api/team, GET /api/team/me,
  PATCH /api/team/members/{id}).

• API keys (sb_…, sent as a bearer token): for scripts, CI and servers, each acts for the
  superuser who made it, with a role up to theirs, and optionally an expiry date and IPs it
  works from. Only a hash is kept; the key is shown once. They can't make file tokens
  (POST /api/team/keys, DELETE /api/team/keys/{id}).

• Signing in to the dashboard with OAuth2: the sign-in page shows a button per provider
  set up on _superusers; only existing superusers whose verified email matches get in.

• App users: Settings → App users shows the auth collections your application signs its
  users in with: how many users, which ways to sign in are on, which OAuth2 providers are
  configured, and the redirect URL to register with providers.

Security

• Uploaded images can't run anything. An image's type comes from its bytes, not from what
  the upload says it is. SVG images with scripts, event handlers, animations, embedded
  documents, DTDs or links outside the file are refused, and every image is served with
  X-Content-Type-Options: nosniff and a sandboxing Content-Security-Policy.
• Backups' files are for owners and admins, however the request is made (with a file token
  too).

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.0.0
• Debian/Ubuntu: slonbase_2.0.0_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.0.0-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.0.0-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.