Skip to content

Product Requirements

This document defines the product requirements for Snackbox. Requirements are defined according to RFC 2119.

Most CMS solutions are too heavy, too opinionated, or tied to a specific frontend. Snackbox is a minimal headless CMS that exposes a clean JSON REST API - decoupled from any frontend so teams can build on top of it freely. It is built to run as hundreds of independent, self-hosted instances with minimal operational effort. These two goals - frontend freedom and operational simplicity - drive every requirement below.

Functional Requirements

Must

  • Expose a JSON REST API for managing pages, posts, tags, users, media files, site settings, navigation menus, and social account links
  • Authenticate requests via JWT bearer tokens
  • Enforce role-based access control with at least two distinct roles - see Roles for the full role matrix
  • Support paginated list endpoints for all collection resources
  • Run as a single statically-linked binary with no external runtime dependencies
  • Run as a non-root user
  • Apply database migrations automatically on startup
  • Support graceful shutdown (drain in-flight requests before exit)

Must not

  • Require a network-accessible database (SQLite is embedded)
  • Expose the metrics endpoint on the public API port
  • Store passwords in plaintext

Quality Attributes

Should

  • Provide Prometheus-compatible metrics for HTTP traffic, auth failures, and media upload volume
  • Support configurable CORS origins, rate limits, and upload size
  • Rate-limit authentication endpoints per IP address to slow credential stuffing attacks
  • Ship with deployment artifacts for systemd and Docker
  • Comply with the 12-factor app methodology - see 12FACTOR.md for the current compliance evaluation

Should not

  • Bundle a frontend or template engine

Deployment Constraints

These constraints apply to all supported deployment targets.

Constraint Value
Supported platforms Linux x86-64 and arm64
Minimum RAM 64 MB
Public exposure Must run behind a reverse proxy for TLS termination

Out of Scope

The following are explicitly out of scope for the 1.x line:

  • Frontend rendering or template engines
  • Horizontal scaling / multi-instance coordination (planned for 2.0.0 via MariaDB and Redis backends)
  • S3-compatible media storage (planned for 2.0.0)
  • Kubernetes-native deployment manifests (planned for 2.0.0, depends on MariaDB + S3 backends)