The Philosophy

• One binary, three commands. curl the binary, soli new, soli serve. No bundle install, no npm install, no compile step for your app code.
• Convention over configuration, Rails-style: auto-loaded models/controllers/policies, RESTful resources routing, *_path helpers, ERB-style views.
• Server-rendered first. htmx + Alpine.js ship vendored in every new app; instant navigation and hover prefetch are built into the server. No JS build pipeline — by design.
• SoliDB-native. The ORM speaks to SoliDB. There are no SQL adapters — the stack is integrated top to bottom, and that trade-off is deliberate.
• Fast by default. 170,000+ req/s on a single server: engine-per-worker architecture, production bytecode VM, in-memory asset cache.

What's in the Box

Where Soli Stands Out

Honest Gaps

Things a Rails, Laravel, Phoenix or Django developer will look for and not find. Some are on the roadmap; some are deliberate trade-offs.

Framework surface

• No auto-generated admin panel — a deliberate choice in 2026: every new app ships agent-ready (CLAUDE.md/AGENTS.md, permission presets, /soli-resource), so the bet is that a coding agent plus soli generate scaffold builds you a bespoke admin faster than you'd customize a generic one. If you want a Django-admin-style CRUD UI with zero building, it isn't here.
• View composition — layouts, partials with locals, content_for/named yield, plus a built-in component(name, data) helper (looks in components/, scaffold with soli generate component) with a block form for default + named slots (a c.slot(...) slot-builder), collection rendering, declared props with dev/lint warnings, opt-in fragment caching, a dev component catalog at /__soli/components, and paginate(pagination) for list navigation. Not a full ViewComponent system (no component classes), but a practical, growing step up from raw partials.
• LiveView is young. Patching is DOM-aware — the client morphs nodes in place with keyed reconciliation (soli-key/soli-ignore), so focus and widget state survive updates — and it has collection streams plus reactive live queries, but the directive set is still a subset of Phoenix's: no debounce/throttle, JS commands, uploads, or nested live components.

Auth

The primitives are all here, with no third-party packages: session auth (soli generate auth, Argon2id), JWT API auth (jwt_sign/jwt_verify), native TOTP 2FA (Crypto.totp_generate/verify/uri), and OAuth consumption built on the SSRF-hardened HTTP client — with official step-by-step guides for GitHub and Google sign-in and TOTP. Signing in with another provider is still hand-rolled from those guides — there is no client generator.

Soli can also be the identity provider. soli generate oidc_provider scaffolds a working OpenID Connect provider — Authorization Code with PKCE, discovery and JWKS, consent screen, refresh-token rotation with reuse detection, and key rotation via kid. Rails, Laravel and Django all reach for a third-party package here (Doorkeeper, Passport, django-oauth-toolkit). Be equally clear about the ceiling: it implements the code+PKCE profile and nothing else — no dynamic client registration (RFC 7591), no request objects (JAR), no implicit or hybrid flows, no client-credentials or device-code grants, no front/back-channel logout, no DPoP or mTLS sender constraining, and no token introspection (RFC 7662). Native apps needing custom-scheme redirects are not supported yet either.

soli generate auth is now a one-command, Devise-style suite: login/signup plus password reset (hashed one-time tokens, 2h expiry, no account enumeration), email confirmation with resend, remember-me (HttpOnly persistent cookie, digest-stored token), and account lockout with auto-unlock — all as readable scaffolded code you own, with the thresholds as constants at the top of the generated User model. What's still assembled by hand: unlock emails and a change-email flow.

Data layer

• SoliDB only. No PostgreSQL/MySQL/SQLite adapters, no multi-database support. If your data must live in SQL, Soli is the wrong tool today.
• Dirty tracking is value-based (changed?, changes, previous_changes, attribute_was exist, but in-place mutation of a nested Hash/Array isn't tracked — no attribute_will_change!), through: associations can't be eager-loaded (<< pushes create the join record, but includes of a through relation raises), and cascade deletes / counter caches skip bulk writes (delete_all/update_all — matching Rails; reset_counters repairs drift).
• Migrations roll back one step at a time — no STEP=n, no version targeting, no schema dump, no db:reset.
• Uniqueness validation is only race-safe when backed by a database unique index — the same caveat as Rails' validates_uniqueness_of; Soli maps the index's 409 back into _errors automatically. (Conditional if:/unless: and per-operation on: create/update validation forms exist.)

Testing

The runner (parallel workers, isolated per-worker databases, coverage with a CI gate) is strong. with_transaction rolls back per-example DB writes; freeze_time/travel_to pin datetime_now(); factories support callable templates, #{n} interpolation, and Factory.insert. Request specs can also assert on the database itself — assert_no_n_plus_one, assert_query_count, assert_max_queries, or the suite-wide soli test --fail-on-n1 guard — failing on N+1s and query-budget regressions that Rails and Laravel only surface through third-party gems (Bullet, prosopite). Browser testing is built in: soli test --browser drives a real headless Chrome over the DevTools protocol — visit, click, fill_in, assert_text — with no Node, no npm and no Playwright install, and the HTTP cookie jar carries into the browser so login() still works. Responsive behaviour is testable too: a viewport("mobile") declaration in a describe body renders every test in it at an emulated device, touch and pixel ratio included — the equivalent of Capybara needing a driver-specific resize_window. Still missing: no mocking/stubbing framework, and no test filtering/watch/fail-fast flags.

Operations

• No TLS in-process — you front Soli with a reverse proxy (HTTP/2 is cleartext-only behind it). Deliberate, but different from Phoenix.
• Jobs require a SolidB server — there is no standalone worker daemon and no dashboard (no Sidekiq/Horizon equivalent). The opt-in in-process pool for long jobs is fire-and-forget.
• Observability stops at metrics. Prometheus counters at /_metrics, health and readiness probes, and a rich per-request breakdown in --dev — but no distributed tracing and no structured (JSON) log output. There is no OpenTelemetry exporter, so Soli cannot yet join a trace that spans your other services, and production logs are human-formatted rather than machine-parseable. Rails, Laravel, Phoenix and Django all have mature OTel integrations.

Ecosystem

This is the honest big one: Rails has ~180k gems' worth of ecosystem, Laravel has first-party packages for billing, search and admin, Django has 15+ years of reusable apps. Soli's package registry is young. What's in the box is unusually broad — but if it's not in the box, you're writing it.

The basic package hygiene is in place, though: a project can pin a minimum interpreter version with soli_version in its soli.toml — MSRV-style, like Cargo's rust-version or Bundler's required_ruby_version — so a too-old soli fails fast with an upgrade message instead of a cryptic runtime error.

Head-to-Head

When to Choose Soli

Bottom Line