Highload platform that lets you build anything with data. Built for longevity.
Content · Commerce · Community · Workflow · Any Data · One runtime, zero compromises.
Rust + Tokio — the name is right there in the product.
Rust is the language that eliminates entire categories of bugs before the program ever runs. No null pointer crashes, no memory leaks, no silent data corruption, no "works on my machine." The compiler is the first line of defense, and it does not negotiate.
Tokio is the async runtime that sits beneath everything and acts as the engine. While most platforms struggle to handle a few hundred simultaneous requests before reaching for extra servers, Tokio-backed services routinely handle tens of thousands of concurrent connections on a single machine — without thread pools, without GC pauses, without drama.
Together they produce something that feels almost unfair: a platform that starts in 50 milliseconds, handles 450,000+ requests per second, and catches type errors, missing fields, and domain contract violations at compile time rather than at 2 AM in production.
RusTok is a modular platform for building any product that has data. Not just a CMS. Not just an online store. A platform where you pick the modules you need — content, commerce, community, workflow, integrations — and they assemble into one coherent runtime.
Think of it like Lego for backend systems: each module is a self-contained brick with its own data model, API surface, and UI. Modules know how to talk to each other through typed events. The entire structure is verified at compile time — not at runtime, not with plugins that might break on the next update. If it compiles, the contracts are sound.
RusTok is designed for teams that are tired of duct-taping multiple platforms together, paying for SaaS services that charge per seat, or inheriting a codebase where "just add a plugin" has become an act of courage.
If it has data, you can build it on RusTok. Here are some examples — and this list barely scratches the surface:
Stores & Commerce
- An online store with product catalog, variant pricing, inventory tracking, multi-currency checkout, and fulfillment workflows — all in one platform, not five integrations stitched together.
- A marketplace where multiple vendors sell under one roof, each with their own products, pricing zones, and order flows.
- A B2B platform with customer-specific pricing, regional rules, and approval workflows before orders go through.
Content & Media
- A blog or editorial publication with authored content, rich media, categories, tags, comment threads, and a full-text search that actually works.
- A news portal or magazine with scheduled publishing, editorial workflows, and localized content for different regions.
- A documentation hub or knowledge base where pages, navigation, and search are first-class citizens.
- A media asset library where images, videos, and files are stored, tagged, versioned, and served through a unified API.
Community & Social
- A forum or discussion platform with categories, moderated topics, threaded replies, and user profiles.
- A community around a product — where customers can ask questions, share reviews, post in forums, and earn reputation — all integrated with the same store they buy from.
- A membership site where access to content, forums, and features is gated by subscription tier.
SaaS & Multi-tenant Products
- A multi-tenant SaaS where each client gets their own isolated workspace with independent module configuration, their own users, roles, and data — without separate deployments.
- A white-label platform where different tenants run different feature sets: one has commerce enabled, another runs content-only, a third has both plus workflow automation.
- An internal platform where multiple teams share infrastructure but operate in isolated namespaces.
Workflow & Automation
- A business process platform where actions trigger events, events trigger workflows, and workflows can call webhooks, send emails, update records, or notify other systems.
- An operations tool where order status changes, inventory alerts, and fulfillment events flow through automated pipelines instead of manual processes.
- An integration hub where external systems push data in via webhooks and pull results out via REST or GraphQL.
APIs & Headless Backends
- A headless backend for a mobile app, where the platform handles auth, data, search, and file storage while the app team owns the UI completely.
- A GraphQL API server for a React/Vue/Svelte frontend, with full RBAC, multi-tenancy, and event-driven writes baked in.
- A backend for a desktop application, IoT dashboard, or any system that needs structured data, roles, and real-time updates.
Enterprise & Highload Platforms
- A full CRM — leads, deals, pipelines, contacts, companies, activity logs, forecasts, and team collaboration — where every customer interaction feeds into automated follow-up workflows and the entire sales funnel is queryable in real time across tens of millions of records.
- An ERP core — finance, HR, procurement, warehouse, and production management — built on the same module system, where adding a new business domain means adding a module, not spinning up a new service with a new team.
- A pharma or life-sciences platform — batch records, clinical trial data, regulatory submission tracking, full audit trails, and controlled-access data rooms — where the type-safe, tenant-isolated architecture maps directly to compliance requirements.
- A financial services backend — transaction ledgers, compliance reporting, multi-currency accounts, risk scoring, and customer KYC flows — where single-digit millisecond latency and tamper-evident event logs are non-negotiable.
- A logistics and supply chain platform — shipment tracking, carrier integrations, warehouse operations, route feeds, and SLA monitoring — where thousands of status events per second need to be processed without queuing nightmares.
- A healthcare data platform — patient records, appointment scheduling, billing, referral workflows, and access control — where multi-tenancy maps naturally to clinics or hospital networks, and data isolation is a regulatory requirement, not a feature request.
- A real estate management system — listings, leads, transaction pipelines, document workflows, agent performance, and portal feeds — running across multiple brands or regions in a single deployment.
- A media and publishing platform at scale — ingesting thousands of articles per day, running editorial workflows, serving content to millions of readers, with per-region localization and search that keeps pace with write velocity.
- A developer infrastructure platform — feature flags, A/B experiments, deployment metadata, usage analytics, and API rate limiting — the kind of internal tooling that large technology companies build and rebuild, available as a configurable module set.
Mission-Critical Financial Infrastructure
Somewhere in the basement of every major bank, insurance company, and clearing house, there is a COBOL program running. It was written in the 1970s or 1980s by people who are now retired. Nobody fully understands it. Nobody dares to change it. And it processes trillions of dollars every single day.
COBOL earned that trust the hard way: it is explicit, it does not crash silently, and it has been running without memory leaks for decades because it has no garbage collector and no dynamic allocation surprises. It is, in its own way, a language built for correctness over developer convenience — and that correctness is exactly why no one has replaced it.
Rust is the modern answer to that same design philosophy — and then some. The ownership model is stricter than anything COBOL's type discipline ever provided. The compiler catches data races that mainframe batch processing never had to worry about but modern concurrent systems face every millisecond. And unlike COBOL, Rust produces binaries that handle real-time workloads: hundreds of thousands of transactions per second, sub-millisecond authorization decisions, streaming risk calculations — without a mainframe lease, without a team of specialists who remember how to operate one, without a six-month migration project just to change a business rule.
RusTok is the platform layer on top of that foundation:
- Core banking systems — account hierarchies, transaction ledgers, multi-currency balances, interest accrual, daily reconciliation, and batch settlement — auditable by regulators, readable by developers, and fast enough for real-time balance queries at scale.
- Payment processing — authorization pipelines that make accept/decline decisions in under 5 milliseconds, fraud signal aggregation across hundreds of risk factors, velocity checks, and routing logic that handles network failures gracefully rather than silently.
- Clearing and settlement — netting calculations, position management, end-of-day batch processing, SWIFT message handling, and cross-border settlement workflows — the infrastructure that makes money actually move between institutions, reliably, every time.
- Insurance platforms — policy lifecycle management, premium calculation engines, claims intake and assessment workflows, reinsurance treaties, actuarial data pipelines, and regulatory solvency reporting.
- Credit and lending — loan origination, scoring models, disbursement workflows, repayment schedules, arrears management, and Basel-aware capital reporting — all in one domain model, not scattered across five connected services.
- Anti-fraud and compliance — real-time transaction monitoring with configurable rule engines (powered by Alloy, no deployment required to update a rule), suspicious activity detection, AML/KYC pipelines, GDPR-compliant audit trails, and case management for compliance teams.
- Trading infrastructure — order management systems, portfolio valuation, risk exposure calculations, P&L attribution, and position reconciliation across custodians — where a wrong number at 9:31 AM costs more than a year of engineering salaries.
The arguments that kept COBOL alive — it has to be correct, it has to be auditable, it cannot lose data, it has to run for 40 years without rebooting — are exactly the arguments that describe Rust at the language level and RusTok at the platform level. The difference is that RusTok starts in 50 milliseconds, handles 45,000 requests per second, runs on commodity hardware, and doesn't require a conference call with a mainframe vendor to change a field name.
The common thread: if your product has users, data, and business rules — RusTok gives you the foundation instead of forcing you to build it from scratch or stitch together cloud services.
Every platform eventually runs into the same wall: the business wants to change how something works, but making that change requires a developer, a pull request, a code review, a deployment, and a maintenance window. For a pricing rule. For an input validation. For a notification message.
Alloy is how RusTok breaks that wall — without sacrificing type safety, auditing, or platform stability.
Alloy is a scripting runtime embedded directly in the platform. Business logic lives in scripts stored in the database, activated instantly, and executed inside a strict sandbox where they can read and modify records but cannot harm the system. No deployment. No downtime. No risk of a pricing-rule change breaking unrelated code.
Scripts attach to the lifecycle of any entity in the platform and fire at precisely defined moments:
| Trigger | When | What you can do |
|---|---|---|
| Before create / update / delete | Before the record hits the database | Validate fields, normalize data, calculate values, reject the operation |
| After create / update / delete | After the record is saved | Send notifications, create follow-up records, trigger side effects |
| On commit | After the transaction is confirmed | Call external APIs, sync to third-party systems, push to event queues |
| Cron schedule | On a timer | Generate reports, clean up stale data, renew subscriptions, send digests |
| Manual trigger | On demand | Recalculate a batch, re-send a failed sync, migrate a dataset |
Scripts are written in Rhai — a sandboxed scripting language that reads like simplified Rust and is safe for non-Rust developers to write and deploy:
// Before creating an order: validate, enrich, and protect
if entity["total"] < 0 {
abort("Order total cannot be negative");
}
if entity["customer_tier"] == "vip" {
entity["discount"] = 15;
entity["priority_fulfillment"] = true;
}
validate_email(entity["contact_email"]);
log("Order pre-processed: " + entity["customer_id"]);
The sandbox enforces hard limits on execution time, operation count, and memory. A runaway script cannot take down the platform. If a script calls abort(), the operation is rejected cleanly with the reason returned to the caller.
Scripts in the OnCommit phase have outbound HTTP access. This is how RusTok connects to the outside world without hard-coding integrations into the platform:
- Payment processors — confirm charges, handle refunds, record receipts
- CRM systems — push deal updates to Salesforce, HubSpot, or any REST-based CRM
- Accounting software — export transactions to 1С, QuickBooks, or any API-accessible ledger
- Warehouse and logistics — confirm shipments, update inventory in partner systems
- Communication channels — send Slack messages, trigger SMS via Twilio, post to any webhook receiver
- Data pipelines — stream events to ClickHouse, BigQuery, or any analytics warehouse endpoint
An integration that would take a sprint to build as a native module takes minutes as an Alloy script. When it stabilizes, it can graduate.
When a script has proven its value and runs thousands of times a day, it can be promoted: the same logic rewritten as a native Rust module, compiled into the platform binary, with zero scripting overhead. Alloy is the prototyping and automation layer; native modules are the production layer. The path between them is intentional and explicit.
Every script execution is recorded: when it ran, how long it took, what entity it processed, what it changed, and whether it succeeded, was rejected by abort(), or failed with an error. Execution logs are queryable via API. Scripts have explicit statuses — Draft, Active, Paused, Archived — making the standard workflow: write in Draft, test, activate when confident.
Alloy scripts are short, structured, and purpose-driven — exactly what AI tools generate well. Describe what you want, get a script, validate it in the sandbox, activate it. The feedback loop from idea to running business logic shrinks from days to minutes.
Most platforms make a trade-off: they are easy to start with, but painful to scale, extend, or maintain as requirements grow. RusTok makes a different trade-off: the initial investment is in Rust and a compiled architecture, and the payoff is a platform that stays fast, stays correct, and stays under control.
| Metric | Interpreted platforms | RusTok |
|---|---|---|
| Req/sec (hot path / cache) | 60 – 800 | 3,000,000+ |
| Req/sec (DB-backed API) | 60 – 800 | 200,000+ |
| P99 Latency | 120 – 450ms | < 1ms |
| Cold Boot | 1 – 8.5 seconds | 0.05 seconds |
The Rust HTTP stack (Hyper + Tokio) consistently places in the top tier of the TechEmpower benchmarks — above 6 million requests per second on plaintext, above 3 million on JSON. A real platform with database calls, RBAC, and multi-tenancy overhead lands in the hundreds of thousands. That is still several orders of magnitude ahead of interpreted runtimes, on the same hardware, without a caching layer in front doing the heavy lifting.
What this means in practice: fewer servers, a smaller cloud bill, and a product that absorbs traffic spikes that would bring an interpreted platform to its knees — without an emergency scale-out at 2 AM.
Other platforms rely on developer discipline: remember to validate input, remember to handle null, remember to check permissions. In RusTok, the type system enforces these at compile time. Permission-aware contracts, tenant isolation, and domain boundaries are part of the code structure, not a convention in a wiki.
Most platforms add multi-tenancy as an afterthought — a tenant_id column bolted onto every table, access checks sprinkled in manually. RusTok is built around rustok-tenant from day one: tenant context flows through every request, module enablement is per-tenant, and isolation is a platform guarantee rather than a dev practice.
Platforms that bundle everything together make you pay for what you do not use: memory, startup time, attack surface, complexity. RusTok's modules are explicit compile-time dependencies declared in modules.toml. Want just content and search? Done. Want to add commerce six months later? Enable the module — the contracts are already there.
RusTok does not pick sides in the frontend war. Leptos — a Rust/WASM framework — is headless by default: it communicates with the server over typed APIs just like any other frontend. In the monolith deployment profile, Leptos and the server share the same process for maximum efficiency; outside of that, Leptos is a standalone client like any other. Alongside Leptos, the platform exposes the same data through GraphQL and REST for any frontend: Next.js, mobile apps, desktop clients, third-party tools. Multiple frontends can consume the same server simultaneously — an admin panel, a customer storefront, a partner portal — all sharing one runtime.
| Capability | Typical CMS | Typical e-commerce platform | Headless CMS | RusTok |
|---|---|---|---|---|
| Integrated deployment | yes | partial | no | yes |
| Headless API surface | partial | limited | yes | yes |
| Integrated + headless simultaneously | rarely | no | no | yes |
| Native multi-tenancy | no | limited | no | yes |
| Compile-time module composition | no | no | no | yes |
| Content + Commerce + Community in one runtime | no | no | no | yes |
| Rust performance baseline | no | no | no | yes |
RusTok supports every deployment topology — from a single-binary monolith to fully decoupled multi-frontend architectures. The server is always the same compiled binary; what changes is where the UI surfaces live and what transport connects them.
Leptos apps (admin and storefront) use #[server] functions as their data layer. In monolith mode these become direct in-process calls — no HTTP, no serialization overhead. In any standalone deployment the same code automatically switches to HTTP. GraphQL remains the external API surface for Next.js, mobile clients, and third-party integrations.
| Profile | Admin | Storefront(s) | Transport between layers | Best for |
|---|---|---|---|---|
| Monolith | Leptos SSR (same process) | Leptos SSR (same process) | none — in-process #[server] calls |
Zero infrastructure overhead, WordPress-style simplicity |
| Server + admin embedded, storefront external | Leptos SSR (same process) | Any client, separate process | in-process for admin; HTTP for storefront | Admin stays fast, storefront scales independently |
| All separate | Leptos standalone or Next.js | Any, separate process | HTTP /api/fn/* for Leptos; GraphQL for Next.js |
Large teams, independent release cycles |
| Pure headless | External / custom | Any consumer | GraphQL | Mobile-first, third-party integrations |
| Multi-frontend | Any of the above | Multiple: web + mobile + partner portals | HTTP /api/fn/* or GraphQL per client type |
Multi-brand, multi-channel, marketplace |
| Deployment profile | Traditional CMS (WP, Drupal) | JS CMS (Strapi, Directus) | Headless CMS (Contentful, Sanity) | E-commerce (Shopify, Magento) | RusTok |
|---|---|---|---|---|---|
| Monolith — all in one process, zero HTTP between layers | yes | no | no | hosted only | yes |
| Server + admin together, storefront separate | manual / plugins | partial | no | limited | yes |
| Server, admin, and storefront all separate | manual | yes | yes | headless add-on | yes |
| Multiple independent storefronts | manual | yes | yes | limited / paid tier | yes |
| Same code, transport switches automatically per topology | no | no | no | no | yes |
| Consistent typed API surface across all topologies | no | no | partial | no | yes |
| Path | Role |
|---|---|
apps/server |
Composition root — HTTP, GraphQL, auth, RBAC, events, manifest validation |
apps/admin |
Leptos admin panel (integrated path) |
apps/storefront |
Leptos customer storefront (integrated path) |
apps/next-admin |
Next.js admin (headless path) |
apps/next-frontend |
Next.js storefront (headless path) |
modules.toml is the source of truth for platform modules.
Core modules:
authcachechannelemailindexsearchoutboxtenantrbac
Optional modules:
- Content and community:
content,blog,comments,forum,pages,media,workflow - Commerce family:
cart,customer,product,profiles,region,pricing,inventory,order,payment,fulfillment,commerce
Support and capability crates sit outside the Core / Optional taxonomy:
- Shared/support:
rustok-core,rustok-api,rustok-events,rustok-storage,rustok-commerce-foundation,rustok-test-utils,rustok-telemetry - Capability/runtime layers:
rustok-mcp,alloy,alloy-scripting,flex,rustok-iggy,rustok-iggy-connector
Every module in modules.toml flows through the same pipeline:
modules.toml
→ build.rs generates host wiring
→ apps/server validates the manifest at startup
→ ModuleRegistry bootstraps the runtime
→ per-tenant enablement activates optional modules
This means:
- Build composition decides what code is compiled into the binary. Unused modules are not there — no dead code, no extra attack surface.
- Tenant enablement decides which optional modules are active for a given customer at runtime. One binary, many configurations.
RusTok ships with a built-in Model Context Protocol (MCP) server via rustok-mcp. This means AI agents and LLM tools can interact with the platform directly — query data, trigger workflows, inspect module state — through a typed protocol rather than raw API calls.
Beyond MCP, the platform is structured for agent-assisted development: explicit module contracts, a documentation map at docs/index.md, typed event schemas, and AGENTS.md rules that make the codebase readable and navigable for automated tools.
RusTok is assembled from well-maintained open-source crates:
- Loco.rs + Axum — web framework and HTTP routing
- Leptos — Rust/WASM frontend framework
- SeaORM — async database ORM for PostgreSQL
- async-graphql — type-safe GraphQL server
- Tokio — async runtime (the second half of the name)
- Casbin — flexible RBAC authorization
- Iggy — event streaming infrastructure
The full local-dev guide lives in docs/guides/quickstart.md.
./scripts/dev-start.shThis starts the full local stack:
| Service | URL |
|---|---|
| Backend API | http://localhost:5150 |
| Leptos Admin | http://localhost:3001 |
| Leptos Storefront | http://localhost:3101 |
| Next.js Admin | http://localhost:3000 |
| Next.js Storefront | http://localhost:3100 |
Prerequisites:
- Rust toolchain (version from repository
rust-toolchain.toml) - PostgreSQL for local runtime
- Node.js or Bun for Next.js hosts
trunkfor Leptos hosts
# run all Rust tests
cargo nextest run --workspace --all-targets --all-features
# doc tests
cargo test --workspace --doc --all-features
# format and lint
cargo fmt --all
cargo clippy --workspace --all-targets --all-features -- -D warnings
# dependency and license checks
cargo deny check
cargo macheteSee CONTRIBUTING.md and AGENTS.md for contributor and agent rules.
| Resource | Link |
|---|---|
| Documentation map | docs/index.md |
| Architecture overview | docs/architecture/overview.md |
| Module registry | docs/modules/registry.md |
| Module docs index | docs/modules/_index.md |
| System manifest | RUSTOK_MANIFEST.md |
| Module system plan | docs/modules/module-system-plan.md |
| Platform verification plan | docs/verification/PLATFORM_VERIFICATION_PLAN.md |
| Testing guide | docs/guides/testing.md |
| MCP reference | docs/references/mcp/README.md |
| Agent rules | AGENTS.md |
RusToK is released under the MIT License.