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 — a generated app has no package.json at all, and Soli compiles its Tailwind with a checksummed standalone binary it fetches once per machine.
• 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 by default. The full ORM surface (graph, vector, columnar, timeseries, raw SDBQL) speaks SoliDB. SOLI_DB_ADAPTER=postgres, mysql, or sqlite gives document CRUD + aggregates + batched includes, and table "…" maps a model onto a table's real columns (CRUD, hash .where, aggregates, batched associations, group_by, bulk writes, transactions, encrypts, STI), which migrations can now create portably, over a TLS connection when the server wants one — still not full SQL parity (no composite primary keys; raw SQL goes through Model.find_by_sql), and deliberate about that ceiling. See docs/sql-adapter-design.md.
• 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.
• Attachments are first-class. has_one_attached("avatar") / has_many_attached("photos") store on disk by default (or s3 / solidb), generate attach_/detach_/_url methods, and purge on delete. The older uploader(...) form still defaults to SoliDB blobs. Ingest is buffered in memory under a per-request cap and an aggregate in-flight budget, so uploads are bounded rather than streamed: there is no direct-to-storage browser upload and no resumable/tus path.
• 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, reactive live queries, debounce/throttle, JS commands, soli-patch / soli-live navigation, nested child sockets, shared-state live_component assigns, send_update / child event == "update", client hooks, loading/disable-with, click-away, chunked soli-upload, and reconnect state restore. Child components are not OTP processes (no cross-process send_update). Pause/resume of a mid-flight upload is still missing.
• EUI is the second real-time UI stack, and it is not a browser one. A component declared with router_eui uses the same LiveView machinery — same registration, same {event, params, state} -> state handler, same worker pool — but its view returns a node tree as plain data rather than an HTML template, and the server sends it as compact binary patches over /_eui/session/<component>. A Rust client lays it out and draws it on the GPU, so there is no document engine running and a counter idles at a few megabytes and no CPU. It is in the default feature set. The cost is the client: this reaches a native application, not a web page — a browser opening an EUI address gets a short page explaining what the address is. A page can also be served as one render with no session behind it, and one corner of it made live with an island, which is how a mostly-static page stops paying a session per reader; the client half of islands is not built yet.

Auth

The primitives are all here, with no third-party packages: session auth (soli generate auth, Argon2id), JWT API auth (jwt_sign/jwt_verify) and PASETO v4 for teams who would rather not have a negotiable algorithm at all, native TOTP 2FA (Crypto.totp_generate/verify/uri), and OAuth client scaffolding via soli generate oauth github|google (state CSRF, find-or-create user, session login) — plus guides for GitHub, Google, and TOTP.

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.

OAuth client (sign in with a provider) is now a generator too: soli generate oauth github / google (requires auth first). See OAuth Client. The generated flow uses state CSRF and PKCE S256, and status-checks every provider response. Ceiling: GitHub and Google only in v1 — not a full OmniAuth catalog.

soli generate auth is 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 + Secure persistent cookie, digest-stored token, revoked on password reset), per-IP throttling on all three credential endpoints, a 12-character minimum enforced from one place by both sign-up and reset, 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. Sign-in is enumeration-resistant on both channels: same message and same Argon2id cost whether or not the address exists, with the “locked” message held back until the password verifies. What's still assembled by hand: unlock emails and a change-email flow.

Data layer

• SoliDB is the full stack; the SQL adapters cover two narrower modes. Set SOLI_DB_ADAPTER=postgres, mysql, or sqlite + DATABASE_URL for document CRUD, hash-style .where (equality, comparisons, IN, LIKE, OR), sum/avg/min/max, multi-row group_by, batched includes (belongs_to/has_many/has_one/HABTM/through:, including a hash filter on the related rows), .join, .having, transactions, SQL migrations, soli db:schema:dump/load, and soli db:import. Declaring table "orders" instead maps a model onto a schema's real columns — introspected at boot, with the same portable query surface (CRUD, hash filters, aggregates, .join/.having, batched associations including HABTM and through:, bulk writes, atomic counters, soft_delete when the table has a deleted_at column, encrypts on text columns, and STI when the table has a string type column); composite primary keys are not supported there. Migrations build those tables portably (create_table("orders", { … }) with a column hash, plus add_column / add_index), and a migration can declare the connection it belongs to. Model.find_by_sql is the raw-SQL escape hatch. Indexes declared with index are created as expression indexes, and the dev bar's query log, N+1 detection and --fail-on-n1 cover SQL. Connections to Postgres and MySQL are TLS-capable (rustls): ?sslmode= / ?ssl-mode= with the libpq ladder from disable to verify-full and an optional CA file, opportunistically encrypted by default — so a managed database (RDS, Cloud SQL, Neon, PlanetScale) no longer needs a proxy in front of it. Graph, vector, columnar, timeseries, and raw SDBQL remain SoliDB-only. SQLite runs the same surface from a single file with no server — one writer at a time, and no exact numeric type. See Column-aware models, PostgreSQL, MySQL, and SQLite.
• 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!), and cascade deletes / counter caches skip bulk writes (delete_all/update_all — matching Rails; reset_counters repairs drift). through: eager loading works on the SQL adapters (document and column mode); the AQL shape on SoliDB still declines it.
• Migrations roll back one step at a time — no STEP=n, no version targeting, no db:reset. soli db:schema:dump / db:schema:load capture and restore dialect SQL plus applied versions on the SQL adapters.
• 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 can scale off HTTP — soli jobs (alias soli worker) runs the poller and pool with no HTTP listener; set SOLI_JOB_WORKERS=0 on soli serve so the web process only enqueues. /__soli/jobs is the queue UI (list, cancel, retry) in --dev and, in production, behind HTTP Basic (SOLI_JOBS_USER / SOLI_JOBS_PASSWORD) or a bearer token (SOLI_JOBS_TOKEN). Unconfigured production answers 404. The CLI and Job.* still work without the page.
• Observability is opt-in rather than auto-instrumented everywhere. Prometheus counters at /_metrics, health and readiness probes, structured JSON logs (SOLI_LOG_FORMAT=json), and OpenTelemetry traces (W3C traceparent + OTLP/HTTP JSON export of the same span tree the dev-bar flamegraph uses) are all first-party — see Observability. So is error tracking: failed requests are grouped, redacted and triaged at /__soli/errors from the app’s own database, where Rails, Laravel and Django reach for Sentry, Honeybadger or Flare — though HTTP failures only. Slow database queries get the same treatment at /__soli/slow_queries (grouped by shape, slowest runs kept with their binds), and new errors, regressions, error spikes and new slow queries can notify Slack, Teams, Discord, Google Chat, any webhook, email or a job of your own — basic alerting, without per-user routing or on-call schedules. What is still thinner than the big four: no auto-instrumentation of every third-party client library, no OTLP metrics/logs pipelines beyond traces, and no sampling UI — you point Soli at a collector (Jaeger, Grafana Tempo, Datadog agent, …) and configure sampling there.

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, and on one axis Soli goes further than the three of them. soli_version in soli.toml declares a minimum interpreter version MSRV-style, like Cargo's rust-version or Bundler's required_ruby_version, so a too-old soli fails fast with an upgrade message rather than a cryptic runtime error. Prefix it with = and it becomes an exact pin: soli inside that project fetches, verifies and switches to that version, the way rustup reads a toolchain file — something Rails, Laravel and Django all need a separate tool for (rbenv, asdf, pyenv). One field, no extra dotfile, and older soli binaries ignore the pin instead of choking on it.

Head-to-Head

When to Choose Soli

Bottom Line