- Cloud
- Edge
- Ground
- Orbit
The intelligence layer between cloud and orbit.
Bring your AI model and your objective. Auvryn handles the complexity between the model and the infrastructure that executes it.
Orbital AI Infrastructure · Early access
01Your model
Bring your model.
Start from what your team already trained. Auvryn takes the ONNX file, verifies its SHA-256, checks it with the ONNX checker and can test it once in an isolated sandbox before anything runs.
- File
- model.onnx
- format
- ONNX
- checksum
- sha256 verified
- validation
- onnx checker
- sandbox
- no network · read-only
02Your objective
Define where it matters.
Draw an area of interest. A model and a place make a workload: the same vessel detector, pointed at an Atlantic shipping corridor.
AOI · Atlantic shipping corridor · 36.5° N · 15.0° W
03The problem
Infrastructure is fragmented.
Every environment exposes a different operational model. Cloud regions, edge devices, ground stations and computers in orbit each bring their own access, packaging, limits and schedules.
- APIs
- Credentials
- Schedules
- Hardware
- Dataflows
- Providers
04The layer
Your model shouldn’t care where it runs.
Auvryn provides a common execution layer between your AI model and the infrastructure that executes it.
ModelAuvrynInfrastructure
05Orchestration
One lifecycle, every time.
The same five steps for every workload. You choose the infrastructure and see the expected cost before anything runs.
- 1ValidateThe model is checked and sandbox-tested.
- 2PrepareModel, area and parameters become one workload.
- 3EstimateThe provider you choose quotes the run.
- 4ExecuteOne durable submission, safe to retry.
- 5RetrieveResults come back with SHA-256 and provenance.
06Where it is going
From a sensor in orbit to a result on the ground.
One pass over the area: the sensor captures, the data comes down to a ground station, reaches Auvryn, and returns as a result.
- Sensor
- Downlink
- Ground
- Auvryn
- Result
An illustration of the path Auvryn is designed for. Today, runs execute on a development provider; orbital and ground providers connect as their access opens.
07 · The platform
One interface for the execution lifecycle.
Everything above collapses into one product: models, areas, infrastructure, estimates, runs and results.
Real product
This is the product, not a mockup.
Screens from the running application, captured on the demo workload. Estimates and runs come from the development provider, which is simulated and labelled as such.
Model, area and the provider you chose, with its estimate, before anything runs.
Proof
This isn’t just a concept.
Each of these is built, and covered by automated tests in the repository.
01
Real ONNX validation
Every uploaded model is inspected by the ONNX checker before it can run.
02
Sandbox isolation
Test runs execute in a container with no network, a read-only root and an unprivileged user.
03
Durable orchestration
Runs survive worker restarts; one provider submission per run, guaranteed by idempotency keys.
04
Result provenance
Each result records the model version, area, provider and estimate it came from.
05
SHA-256 verified artifacts
Models and results are checksummed; downloads are verified against them.
06
Developer API
REST with an OpenAPI 3.1 description, scoped expiring keys and idempotent creates.
07
TypeScript SDK
The full workflow from code, typed from the API contract.
08
CLI
The same workflow from a terminal or a CI pipeline, with exit codes.
09
MCP server
AI agents use Auvryn through an execution gate and scoped keys.
Tell us what it does and where it should look.
Run completed
Result ready
- artifact
- result.json
- sha256
- verified
- provenance
- model · area · provider · estimate
- provider
- Development provider
From the demo workload, on the development provider: a detection model over one area, run once, stored with its checksum.
Developers
One workflow, any interface.
The web app is one client among several. The same scoped API key works from code, a terminal or an AI agent.
AI agents operate through the same permissions and execution boundaries as any other client.
The SDK and CLI are 0.x and not yet published to npm; design partners get them directly.
import { Auvryn } from '@auvryn/sdk'; const auvryn = new Auvryn({ apiKey: process.env.AUVRYN_API_KEY }); const estimate = await auvryn.estimates.create({ projectId, modelVersionId, areaOfInterestId, providerId,});const run = await auvryn.executions.create({ projectId, costEstimateId: estimate.id, idempotencyKey,});const job = await auvryn.executions.wait({ projectId, jobId: run.id });const result = await auvryn.results.get({ projectId, jobId: job.id });One client, one key
What
What could your model do next?
Four examples, one execution layer. The domain and the model are yours; Auvryn runs them.
Your modelAuvrynSelected execution environmentResult
- 01Maritime intelligenceMaritime intelligence at scale.
- 02Wildfire & disaster responseTurn observation into actionable information sooner.
- 03Agriculture & environmentIntelligence across areas too large to inspect manually.
- 04Infrastructure monitoringMonitor distributed infrastructure without multiplying execution stacks.
Examples of what teams run and what their models return, not Auvryn features. Regions are illustrative, never customers. You select the execution environment; Auvryn shows the expected cost before anything runs.
Your model. Your domain.Auvryn underneath.
Auvryn doesn’t decide what your AI should detect. It gives your model a common execution layer across increasingly heterogeneous infrastructure.
Auvryn is built for teams that already own the intelligence and need a better way to execute it.
Have a model like this?
Bring your modelWe’re working directly with early design partners on real AI workloads.
Where
Where could your model run next?
The same workload, on increasingly heterogeneous infrastructure. One provider contract and one execution lifecycle cover all of it; you choose the infrastructure and see the expected cost before anything runs.
- 01CloudRegions where your model runs today, through one contract instead of one integration each.
- 02EdgeDevices and sites closer to the data, under the same lifecycle.
- 03SensorsInstruments in orbit that acquire what the model reads.
- 04OrbitComputers in orbit, and the ground stations that bring their results down.
Provider neutrality is what keeps your model portable as this list grows.
Security
Boundaries that hold for every client.
Tenant isolation
Another workspace’s resources answer “not found”.
Scoped API keys
Keys carry scopes, can be limited to a project, expire, and are stored only as hashes.
Sandbox isolation
Models are tested without network access, as an unprivileged user.
Server-side provider credentials
Provider credentials never leave the server.
Verified result artifacts
Results are stored by Auvryn with their SHA-256.
Provenance
Every result is traceable to the model, area and provider behind it.
No compliance certifications are claimed.
Where it runs today
Honest status.
Provider-neutral by design. This is what each integration is today.
| Provider | Status | |
|---|---|---|
| Development provider A simulated provider, labelled as such in the product. Every demo and test run uses it, end to end: estimate, execution, result. | Compute | Operational for validation and demos |
| TakeMe2Space / OrbitLab The orbital compute integration has been investigated. It is not built: it is waiting for provider API access. No partnership is implied. | Orbital compute | Integration investigated, waiting for provider API access |
| AWS Ground Station It reads ground-infrastructure information to validate the architecture. It executes nothing and reserves nothing. | Ground | Read-only architectural integration |
FAQ
Questions, answered plainly.
Does Auvryn own satellites?
No. Auvryn owns no satellites, ground stations or data centers. It is the software layer that runs your model on infrastructure operated by providers.
Does Auvryn provide imagery?
No. Auvryn is not an imagery marketplace. You bring the model and say where it should look; the data comes from you or, in the future, from a provider’s sensor.
Can I use my own model?
Yes, that is the point. Today Auvryn accepts ONNX models. It validates them with the ONNX checker and can test them in an isolated sandbox before anything runs.
Can it execute in orbit today?
No. The architecture is designed for orbital compute, ground stations and connectivity, and the provider contract is ready for them. No orbital execution has happened through Auvryn yet.
Which providers are supported?
Provider-neutral by design. Today: a development provider for validation and demos; an orbital compute integration investigated and waiting for provider API access; a read-only ground-station integration. Details in the status table above.
How does pricing work?
There is no public pricing yet; we are in the design partner stage. Before every run Auvryn shows the provider’s cost estimate, and it records usage afterwards. Auvryn does not bill.
What happens to my model?
It is uploaded straight to Auvryn’s storage and its SHA-256 is verified. It is validated without being executed; the optional sandbox test runs it once, without network. When you run a workload, the provider you chose receives access to it.
Who owns the results?
Result artifacts are copied into storage Auvryn controls, with their size and SHA-256, and only your workspace can read them. Legal ownership terms are set in the design partner agreement.
The missing layer
The missing layer
The models already exist.
The execution environments are multiplying.
Cloud.
Edge.
Sensors.
Orbit.
The missing layer is between them.
Auvryn.
Early access
Work with Auvryn on a real model.
Auvryn is in early access. We’re working directly with early design partners.
Have a model you want to run beyond today’s infrastructure?
Ready to run something real?
You reach the team building Auvryn directly. No sales funnel. hello@auvrynspace.com