What's in the Box

What’s in the Box

Sillo is described as batteries-included, which is true about its surface and misleading about its install. The base install is five packages. Everything that carries a third-party dependency is something you ask for.

This page is the map: what comes with the framework, what is one flag away, what is a separate install, and what is a tool rather than a library. It describes the 0.x line — the released one. Four of these boundaries move in 1.0, and the last section says which.

The base install

uv add sillo-framework

Five dependencies: uvicorn, anyio, python-multipart, pydantic, and typing-extensions below Python 3.13. Python 3.10 or newer.

What that gives you, with no further installs:

• the async ASGI application, routing, routers and sub-apps
• handlers, the request context and the response builder
• request validation with Pydantic, and OpenAPI generation from the same declarations
• dependency injection
• the middleware pipeline, with CORS, CSRF, security headers, sessions, rate limiting, ETags and content negotiation as first-party middleware
• authentication, permissions, API keys and session auth (JWT needs the jwt extra)
• password hashing, falling back to pbkdf2_sha256 from the standard library when no backend is installed
• background tasks, queues, jobs and the scheduler
• caching and events, in memory
• WebSockets
• object storage with local and in-memory drivers
• static files, file uploads and streaming responses
• the sillo CLI — a console script, not an extra
• the test client and an HTTP client
• typed configuration and .env loading

Note what is not on that list: a database, a Redis client, and a JWT library.

Also in the framework, in 0.x only

Four subsystems are part of the framework on this line and become separate packages in 1.0. They are documented here because this is the released version, not because they are permanent:

• the admin panel, over your Record models
• HTML templating with Jinja
• WebSocket channels and groups — rooms, not just connections
• GraphQL over a Strawberry schema

See What moves in 1.0 before you build something large on any of them.

The extras

Each of these adds one dependency, for one subsystem.

Extra	Brings	For
record	tortoise-orm	The ORM — models, migrations, factories
jwt	pyjwt	JWT authentication
cache	redis	Caching across processes
events	redis	Event distribution across processes
crypto	cryptography	The encrypted cast and sillo.helpers.crypto
storage-s3	httpx	The S3 storage driver
mail	jinja2	Templated email bodies
hashing-bcrypt	bcrypt	bcrypt password hashing
hashing-argon2	argon2-cffi	Argon2 password hashing
hashing-scrypt	scrypt	scrypt password hashing
hashing-all	all three, plus passlib	All of the above
granian	granian	An alternative ASGI server to uvicorn
all	everything above	Not thinking about it

uv add "sillo-framework[record,jwt,hashing-argon2]"
uv add "sillo-framework[all]"

Note

The extra names above are the ones the current release defines. They have shifted across the 0.x line as subsystems moved — older 0.x releases carried templating and graphql extras, and some pages in this manual still name them. The package metadata for the version you actually installed is the authority; uv pip show sillo-framework will tell you.

Two of these are worth a second look. The S3 driver depends on httpx rather than boto3 — request signing is a few dozen lines of HMAC, and boto3 is a very large synchronous dependency to carry for it. And the hashing extras are separate rather than bundled because a project standardises on one algorithm; installing three compiled backends to use one is exactly the imposition the extras exist to avoid.

Separate packages

These are not extras. They are their own distributions, versioned and released on their own cadence, because each has a dependency, a release rhythm, or a scope that the framework should not carry on everybody’s behalf.

Package	Install	Import	What it is
Wire	sillo-wire	sillo.wire	Rooms, presence, replay and fan-out for WebSockets
GraphQL	sillo-graphql	sillo.graphql	A production GraphQL endpoint over a Strawberry schema — see the caveat below
Warder	warder	warder	A declarative admin panel over your models, with a React interface
Inertia	sillo-inertia	sillo_inertia	Server-driven pages with React or Vue, no API layer
OAuth	sillo-oauth	sillo_oauth	Social login and OAuth2 providers

Wire and GraphQL extend the framework’s own surface, so they also take a name inside it: from sillo.wire import Hub and from sillo_wire import Hub bind the same class. The others keep their own top-level names — Warder most deliberately of all, because it is not an extension of sillo but an application you mount on yours. The Packages index explains how the aliasing works and why it is not a directory shipped into the framework.

Caution

sillo-graphql claims sillo.graphql, which the framework itself still ships on this line. A package cannot claim a name the framework is using, so against 0.x the alias refuses to load and says why — rather than quietly shadowing the built-in module. On 0.x, use the framework’s own GraphQL support; sillo-graphql is for 1.0.

The tools

Not libraries you import — programs you run.

Tool	Install	What it does
sillo	ships with the framework	Migrations, users, queues, the scheduler, and your own commands
sillo-start	uv tool install sillo-start	Creates a project by copying a working application, not by generating one
sillo-vise	uv add sillo-vise	vise serve — the development server, with readable logging and the Foreman operations dashboard mounted beside your app
@sillo/atlas	npm	The OpenAPI reference UI and API client, ~79 KB with no runtime dependencies

What moves in 1.0

Four things leave the framework in 1.0. If you are starting something now and expect to follow the framework forward, these are the four to make a decision about rather than discover later.

Here, in 0.x	In 1.0
Built-in admin panel	warder
HTML templating layer (Jinja)	Removed; templated email bodies are the one place a template is still rendered
WebSocket rooms, channels and groups	sillo-wire
sillo.graphql in the framework	sillo-graphql, claiming the same import name

The same reason applies to all four: each had grown a dependency, a release cadence or a scope of its own, and keeping it in core made everybody carry it.

None of them disappear — three become installs and one becomes a design decision you make yourself. The templating removal is the only one without a drop-in replacement: if you are rendering server-side HTML today, decide whether that is where the application is going before 1.0 makes the decision for you.

Deciding what you need

A useful default for a JSON API with users and a database:

uv add "sillo-framework[record,jwt,hashing-argon2]"

Add cache and events when you run more than one process. Add nothing else until something asks for it.

For rooms and presence over WebSockets, and for an admin panel, 0.x has both in the framework — see the channels guide and the admin. sillo-wire and warder are where those go in 1.0.

If you would rather start from a working application than assemble one, sillo-start copies the official starter — session auth against a real user model, migrations, a JSON API and a queue, all already wired together.

Related

• Installation — the actual install steps
• Packages — the manuals for Wire, GraphQL and Warder
• Philosophy — why the line between core and extra falls where it does
• Frequently Asked Questions — including what breaks between 0.x and 1.0