Without an engine
- Logic split across queue handlers, retry loops, and cron jobs
- State reconstructed from logs, after the fact
- "Where is order 2481?" takes an afternoon
- Timeouts and compensation hand rolled per service
Sheptra Cloud · beta not open yet
Draw the process.We run it.
Sheptra Cloud is managed BPMN for .NET teams. Model in the browser, ship immutable versions with one click, and Greyson — the engine we operate — executes every instance. Your workers stay in your services, in your own code.
See how it works
One email, when the beta opens. No newsletter, and we don't pass it on — see our privacy note.
1,035 process instances a second in our load harness — measured, not modelled.
1,035/sprocess instancesstart → complete, one host, no network hop
14.9msend to end, p50same run · p95 18.5ms · p99 28.3ms
0servers to managewe run the engine, you run the business
Betano SLA yettargets get published when we can back them
order-fulfillment.bpmn v14
4 instances active
The problem
Your process already exists. It's just scattered.
The order flow is real — it's spread across queue handlers, retry loops, a wiki page, and one engineer's memory. When it stalls at step four, nobody can point at step four.
With Sheptra
- One diagram, deployed as the executable artifact
- Every transition on the record as it happens
- Live token positions answer "where is it" at a glance
- Durable jobs with retries and leases built in
How it works
From first sketch to millionth instance
Everything your process definitions need lives in one cloud workspace — no modeler licenses, no engine servers, no glue code between them.
01 · Model
Model in the browser
A BPMN modeler lives in your workspace. Draft with autosave, validate as you draw, and freeze numbered versions with notes — plus an audit trail of who changed what.
02 · Deploy
Ship an immutable version
One click from the modeler, or one call from your pipeline, snapshots a version and hands it to the engine. Versions are immutable; rolling back means restoring an older snapshot in the modeler and shipping it as the next version.
03 · Run
Let the cloud take it
The managed engine executes every instance with nothing to provision — durable jobs with retries and leases, timers, and live token positions you can watch.
Your processes are complex. Running them should feel calm.
The Greyson engine
A fast BPMN engine for .NET, run for you
At the heart of Sheptra is Greyson — lightweight, efficient execution of BPMN process models, on infrastructure we operate. There is exactly one version in production, and it is always the current one.
Fast
A lightweight core that executes BPMN models with almost no overhead — 1,035 process instances a second in our load harness, engine and database on one host. Measured, not modelled, and an upper bound rather than a deployment promise.
Your workers, your code
Service tasks park as durable jobs your own services pick up — ordinary C# against your own data, while the engine stays managed. Workers speak the REST job API today; a typed .NET SDK is planned, not started.
Pragmatic
Simple APIs for starting, running, and observing workflows. No ceremony between you and a running process.
Native BPMN 2.0
Run the diagram itself — no translation layer. Exclusive, parallel, inclusive and event-based gateways; timer, message, signal, error, escalation, compensation, link and terminate events; interrupting and non-interrupting boundary events; event sub-processes; multi-instance; user, service, script, send, receive and business rule tasks; sub-processes and call activities — all executing today. Transactions, ad-hoc sub-processes, complex gateways and conditional events are not.
No runtime surprises
A diagram using an element the engine does not support yet is rejected at deploy time, naming the offending element — never discovered halfway through a production instance at 3 a.m.
On the record
Every transition emits an immutable execution step, so the history you read back is the engine’s own record rather than a reconstruction. OpenTelemetry traces span the engine and hand every activated job a traceparent — shipping those traces on to you is still ahead of us.
Decisions, not just flows
DMN decision tables run inside the engine: every hit policy, FEEL expressions evaluated by our own interpreter, and a business rule task that evaluates the table without a round trip to a worker. Decisions are versioned like processes, and you can evaluate one on its own to check the answer before it is wired into a flow.
Humans in the loop
User tasks land in a work queue with assignees and candidate groups from the diagram — claim, unclaim, reassign, complete, every step audited. The task inbox and instance views are ours; the form you put in front of people is still yours to build, because a forms runtime is not here yet.
Operate, not just observe
When an instance stalls you can act on it: resolve the incident, top up retries, publish the message it is waiting for, move a token, or migrate a batch of running instances to the new version — with a preview of what would be touched, and every operator action on the audit trail.
Deploy your way
One click from the modeler, or one command from CI
Publish straight from the browser, or point your pipeline at a .bpmn file. Either way, Sheptra Cloud parses it, validates it, versions it, and runs it.
The diagram is the artifact
No codegen, no DSL drift. The file you deploy is the file your analysts see.
Zero downtime versioning
New instances start on the new version; instances already running finish on the one they started with — or you migrate them in a batch, after a preview shows exactly which ones it would touch.
One version in production
There is no release matrix to reason about. Every fix reaches every customer at once, because we run the only copy there is.
Program.cs
using var http = new HttpClient { BaseAddress = environment };
// ship the diagram, exactly as modeled
var deployed = await http.PostAsync("/v1/definitions",
new StringContent(File.ReadAllText("order-fulfillment.bpmn"),
Encoding.UTF8, "application/xml"));
var id = (await deployed.Content.ReadFromJsonAsync<Definition>())!.Id;
// start an instance — the cloud takes it
await http.PostAsJsonAsync("/v1/instances", new {
definitionId = id, startEventId = "order-placed",
variables = new { orderId = "ord_2481" } });
// service tasks: your worker, your code
var jobs = await http.PostAsJsonAsync("/v1/jobs/activate",
new { types = new[] { "charge-card" }, waitSeconds = 30 });Plain HTTP is the contract today, and this is the real request shape — the typed .NET worker SDK is planned, not written.
Enterprise
The answer to a security review isn't a download
Sheptra runs in our cloud, and only in our cloud. Isolation is meant to be a dial rather than a binary — but only the first rung exists today, so here is the ladder with the honest labels on it.
01 · Rung
Shared plane
TodayLogical isolation per workspace, encrypted at rest and in transit, with a retention window agreed per workspace. What every beta workspace runs on.
02 · Rung
Dedicated database
PlannedAn environment of your own: its own Multi-AZ Postgres, its own API pods, its own scheduler and migration stream. The rung most security reviews actually stop at.
03 · Rung
Dedicated compute
PlannedYour environment moves onto engine nodes of its own — no shared compute anywhere, for the workloads that cannot share any.
04 · Rung
Private link + a dedicated key
PlannedA private endpoint that never crosses the public internet, and a KMS key dedicated to you — held in our account, under a key policy you review and can revoke.
Rung 01 is what every workspace runs on today. Rungs 02 and up are the roadmap, not a menu you can order from yet — if your security review needs one, talk to us and we'll tell you plainly where it stands.
Trust & compliance
Encryption at rest & in transit
SSO with fine-grained permissions
Per-workspace retention & archive
Audit trails: workspace changes, operator actions, execution
SCIM directory sync (via WorkOS)
SOC 2 Type II
Independent penetration test
DPA & subprocessor list
Live today Planned
Pricing
Priced by what actually costs something
Running one more process instance costs us close to nothing, so we don't meter you into a corner. What costs real money is the availability we promise and the isolation we provision — so that's what the tiers are built from.
Developer
Free in betaA sandbox to think in.
- 1 sandbox environment
- 5,000 instances / month
- 3 modeler seats
- 7 day history
- Community support
Team
Coming soonOne process, in production.
- 1 production environment
- 10 modeler seats
- 30 day history
- Email support
Business
Coming soonA pipeline, not a project.
- Dev, staging & production environments
- 25 modeler seats
- 90 day history + archive
- SSO, engine audit log
- Business hours support
Enterprise
Coming soonIsolation on your terms.
- Dedicated environment — your own database, pods and scheduler (roadmap)
- Private networking, a KMS key of your own (roadmap)
- Region of your choice, custom retention
- Unlimited seats within quota
- Uptime and support terms agreed per contract
No prices yet, and nothing here is for sale — we're not going to invent a number, or take a signup, while the platform is still being built. When the beta opens it starts with a free sandbox environment, no card required. The tiers above are the shape we're aiming at, published early so you can tell us where it's wrong.
FAQ
Questions, with straight answers
Not yet. The beta is not open, nothing is for sale, and the request buttons on this page are deliberately inert. The engine runs real BPMN today; the platform around it is still being built, and this page is an honest account of which is which.
The BPMN engine behind Sheptra — a fast, lightweight .NET engine we operate for you. In our load harness it starts and completes 1,035 process instances a second with the engine and database on one host. That figure is measured, not modelled, and it is an upper bound rather than a deployment promise.
No. We run the engine and the modeler. Your side is the workers: ordinary services in your own infrastructure that pick up durable jobs over the REST job API, run your code against your data, and report back.
Most of the executable core. Gateways: exclusive, parallel, inclusive and event-based. Events: timer, message, signal, error, escalation, compensation, link and terminate, as start, intermediate, boundary and end events where the spec allows, including non-interrupting boundary events and event sub-processes. Activities: user, service, script, send, receive and business rule tasks, embedded sub-processes, call activities, and parallel or sequential multi-instance. Not yet: transactions, ad-hoc sub-processes, complex gateways, conditional events and standard loops. Pools, lanes and data objects are kept in the file but do not execute. Anything the engine does not run is rejected at deploy time, naming the element, rather than failing mid-instance.
Yes. Deploy a DMN file and a business rule task evaluates the decision inside the engine — decision tables with every hit policy, literal expressions, and decisions that require other decisions. FEEL is evaluated by our own interpreter and checked against the DMN TCK; the disagreements are counted in the repo rather than hidden. You can also evaluate a deployed decision directly to check an answer.
Planned, not started. Plain HTTP against the REST job API is the contract today — long-polling activation across all your job types in one request, an idempotency key on every write, and a traceparent on every activated job — and the code on this page shows that rather than an SDK that does not exist yet.
Nothing, by default. Versions are immutable: new instances start on the new version, and instances already running finish on the version they started with. When you do want them moved, a migration plan carries a chosen set of running instances to the new version, with a preview of what it would touch before anything changes. Rolling back means restoring an older snapshot in the modeler and shipping it as the next version.
No — Sheptra runs in our cloud, and only in our cloud. Our answer to security reviews is the isolation ladder instead: logical isolation today, with dedicated database, dedicated compute, and private networking on the roadmap. If your review needs a rung that does not exist yet, we will tell you plainly where it stands.
Closest to Camunda 8 in architecture: an external-worker job model, immutable versions, in-engine DMN and FEEL, and a fully managed engine. Forms, connectors and analytics are areas where other products are further along today. The comparison page sets Sheptra beside Camunda 8, Decisions (formerly ProcessMaker), Flowable and Temporal, capability by capability, with every entry linked to the vendor’s own documentation. See the comparison →
There are no prices yet, on purpose. Running one more instance costs us close to nothing, so we will not meter you into a corner — what costs real money is promised availability and provisioned isolation, and that is what the tiers are built from. The bands get published when they are set, not before.
Not yet. We publish availability targets when we can stand behind them with data, and beta workspaces run without one. Enterprise uptime terms will be agreed per contract.
Nothing but the time to try it. It starts with a free sandbox environment — no card, no commitment. Bring a diagram and a real process, and we will tell you straight which parts are not finished.
Why the engine is called “Greyson”
Named for a very good shepherd
Greyson was a miniature blue merle Australian shepherd — one blue eye, one brown — who shepherded our family for thirteen years.
The engine behind Sheptra carries his name. It moves every token with the same calm, reliable presence he gave us every day — always watching, always steady, quietly keeping the flock together. That is where “calm execution” comes from. It described him first.
Your process is already drawn.
Now run it in the cloud.
Not yet — the beta isn't open. When it is, it starts with a free sandbox environment: bring a diagram and a real process, and we'll tell you straight which parts aren't finished. Leave an address and you'll hear the day it opens.
One email, when the beta opens. No newsletter, and we don't pass it on — see our privacy note.