Enterprise-grade from day one, not bolted on later.

What is built in

• On-prem and self-hosted. A single binary whose roles you turn on as you need them. Postgres first; add Kafka, ClickHouse, or Redis by configuration. Nothing leaves your environment.
• SSO through OIDC, API keys, and JWT.
• Access control in layers: role-based, attribute-based down to the row, and field-level. Sensitive fields are separately permissioned and separately audited, with separation-of-duties checks.
• Multi-tenancy enforced at the database, so one tenant cannot see another.
• Secrets encrypted with rotation; we never hold your keys.
• An append-only platform audit: every configuration change, permission grant, login, and change to any record, captured with who, when, and the before-and-after. (The separate decision audit, every policy evaluation, lives in the engine: see Evidence.)
• Observability built in: OpenTelemetry traces and metrics into your own stack (Grafana, VictoriaMetrics, ELK), plus analytics by event, rule, signal, and entity in the console.

Start small, scale horizontally

The minimal setup is a single binary plus Postgres: it comes up in minutes and handles thousands of events per second, which is enough for most deployments. When you need more, the same engine scales out by configuration, not a rewrite: add Kafka as the event transport, ClickHouse for analytics, and database partitioning to scale toward millions of events per second, on Docker, Kubernetes, or VMs. Ingestion, workers, and gateways scale independently. Kafka, ClickHouse, and Redis are optional connectors - transport, analytics and archive, cache - you turn on only when your volume calls for them. Swiftward can also run completely offline, with no internet connection at all, on local models and detectors, so your data never leaves your environment.

Built on a declarative platform, so it bends without breaking

Underneath, Swiftward is declarative: its entities, screens, workflows, actions, and permissions are defined as configuration, and new capability is added at defined extension points rather than by editing the core. That is why the surface above is broad, and, more to the point, it is why a specific thing your review asks for, a new gateway, an extra field, a custom check, is a configuration change or a small isolated extension, not a forked codebase we maintain for you forever. Most vendors answer a custom requirement with a separate branch: slow to build, costly, and a burden to keep alive across upgrades. Here the core stays untouched and the addition rides on top. If something you need is not listed, ask, and we will tell you straight whether it is already there or a clean, bounded piece of work.

Embed it under your own product

If you sell software into enterprises, your deals stall in security review until you can show on-prem, audit, and access control. Embed Swiftward's foundation under your product, white-labeled, and walk into the review with those controls already in place. There are three ways to wire it in: a generated API over every entity and action, a React SDK, or any screen embedded as a white-labeled iframe with a short-lived, per-tenant token. It is the enterprise layer you would otherwise spend a year or more building. Make your product enterprise-ready