Architecture · Foundation

The runtime your apps inherit on day one

Underneath everything sits the orchestration kernel: the credential broker that keeps secrets out of code, the service that owns the deploy lifecycle, and the runtime that actually runs the apps.

The credential broker resolving a managed auth alias at runtime so no secret reaches the app code

Every AI-built app rebuilds the same plumbing badly

Connecting to a system, storing a value between runs, shipping a new version. Each builder solves these from scratch, and each solution is one more thing nobody is maintaining.

A pasted key per integration

Reaching Salesforce or Slack means finding a credential and putting it somewhere. It ends up in the repo and outlives the app.

No place to keep state

An app that needs to remember something between runs needs a database, which needs a request, which stalls the app.

Versioning by copy

Without a deploy lifecycle there is no clean way to ship a change, and no way back when a change goes wrong.

Infrastructure nobody owns

Hosting, TLS, and scaling are not things the person who built the app in Cursor can stand up, so the app never ships.

Solved once, inherited by every app

The same Tray.ai runtime that already moves 1T+ processes a year, at 100% execution uptime.

The credential broker

Secrets never in code

Apps reference a managed auth alias, and the broker resolves the real credential at runtime. The builder and the AI assistant never see it.

Nothing to leak
The credential never enters the repository, the config, the environment, or the prompt, so there is nothing for a scanner to find later.
Revoke in one place
Rotating or withdrawing access is a change to the alias, not a code change across every app that used it.
Connected to your systems
Salesforce, Google Sheets, Slack, and the rest of the supported list, through managed auth rather than a pasted key.

The project service

Deploy lifecycle and versioning

What it means to ship a change, keep track of versions, and know how an app reached production.

A repeatable deploy
Every app follows the same path, so a deploy can be reviewed and reproduced rather than reverse-engineered.
Versions, not copies
Shipping a fix goes through the same route, and the registry entry and managed auth carry forward with it.

The runtime

Where the apps actually run

Managed hosting with the services an app needs, so no builder has to request infrastructure to go live.

Managed hosting
One command takes an app to a live URL. IT stands up nothing.
Built-in persistence
A key-value store so apps hold state between runs without a database. Storage limits apply.
Core security
Identity and integration security applied by the platform rather than assembled per app.

Foundation is the orchestration kernel. It is the part builders never think about and the part that makes everything above it possible: the credential broker so secrets never reach the code, the project service that owns deploy and versioning, and the runtime that actually runs the apps. This is not new infrastructure written for Helix. It is the platform that already moves 1T+ processes a year, which your AI-built apps inherit the moment they deploy.

Build on a runtime that already runs at scale

See what your AI-built apps inherit the moment they deploy.