Your teams build in the AI assistant they already use. Helix takes the apps and agents they built to production on Tray's managed runtime, and applies governance as they ship.
Thanks, keep an eye on your inbox for an invite.
> helix deploy
✓ Managed auth applied (via auth aliases, no secrets)
✓ Registry entry created (visible to IT)
✓ Access scoped (Marketing workgroup)
● Running on Helix · https://campaign-reporter.helix-app.ai
>
An app that works on someone’s machine is not yet in production. Sitting on a laptop, it is a liability waiting to be discovered. Helix takes an app from any AI coding assistant to a real production deploy and runs it on Tray’s managed runtime, with managed auth, identity, and a registry entry applied along the way. It is built to be easier than the workaround, so builders choose it instead of going around IT.
A working prototype is not a production app. The gap between the two is infrastructure nobody on the build side owns.
The person who built the app in Claude Code cannot stand up hosting, TLS, identity, and secrets management. So the app stays on their laptop.
Every deploy becomes a request to a platform team that is already at capacity. Weeks pass, and the business moves on without the app.
When the governed path is slow, builders take the fast one. An API key goes in an environment variable, and nobody records where.
Apps that do reach production arrive with no owner, no access record, and no place IT can see them.
Take an app from an AI coding assistant to a governed production deploy without hand-rolled scripts, copied credentials, or a forgotten server running under someone's desk.
Build in Claude Code, Codex, Cursor, or another AI assistant and deploy with one command. Teams with a repo can deploy from CI instead: helix ci init writes a GitHub Actions workflow that ships on merge or on demand, signed in as a Tray API user.
Managed auth, identity, and the registry entry are applied as the app ships, so governance is the default of going live rather than a cleanup that happens later.
Helix keeps the source behind recent deployments. Choose Restore on one and Helix rebuilds it through the same pipeline and ships it as a new deployment. If the rebuild fails, the live version keeps serving, so going back never takes the app offline.
A managed runtime with built-in key-value persistence, and agents that ship in the same deploy and run inside the app, so an app has what it needs to run without a builder filing a request for infrastructure.
Add an approval step where the risk warrants it and let low-risk apps flow straight through, so control scales with stakes instead of blocking everything equally.
A Customer 360 app goes from a laptop to a live URL on Tray's managed runtime, with managed auth, identity and a registry entry applied as it ships.
Choose Restore on a recent deployment and Helix rebuilds it from its source through the same pipeline. The version that is live keeps serving until the restore succeeds, so going back never takes the app offline.
Helix is how an app built with AI reaches production safely. It is the route that is easier than the workaround, so builders take it on their own and IT gets control without slowing anyone down.
Control planes fail when routing around them is simpler. Helix is built to be the easiest way to ship, so builders take the governed path by choice, not by mandate.
Builders do not switch tools or learn a platform. They keep building with AI the way they do today and deploy through Helix when it is time to go live.
Policy is applied at the deploy path, not through a manual ticket and a human bottleneck, so saying yes does not slow anyone down.
Instead of a different deploy hack per team and per tool, every app built with AI follows the same governed route to production.
A team builds an internal dashboard in Cursor and deploys it through Helix, with managed auth and a registry entry from the first day it is live.
An app that started as a Claude Code experiment graduates to a governed production deploy without a rewrite or a separate hand-off to engineering.
Instead of running on someone's personal cloud account, an app ships through Helix where IT can see, secure, and control it.
A team that keeps its app in a repo runs helix ci init. Every merge to the default branch deploys to staging, production waits for a reviewer in GitHub, and a failed build fails the job.
A release breaks something, and the builder restores the last good deployment from the project's Deployments tab. Helix rebuilds it while the current version keeps serving, and the app is back in minutes.
An app that touches customer data gets an approval step, while an internal lookup tool flows straight through, so review effort matches risk.
No. They keep using their AI coding assistant of choice. Helix is the path they deploy through, not a tool they build in, so there is nothing new to learn before going live.
Only if going around is easier, and Helix is designed so it is not. When the governed path is simpler than spinning up a personal server and pasting in credentials, builders choose it on their own.
No. The deploy path is where governance is applied: managed auth, identity, and a registry entry all attach as the app ships. The button is the easy surface over real control underneath.
Yes. Run helix ci init in the project and it writes a GitHub Actions workflow that runs helix deploy --wait, set to deploy production on demand, on every merge, or staging on merge with production behind a reviewer in GitHub. CI signs in as a Tray API user, so each deploy is attributed to CI rather than a person, and a failed build fails the job. Any other CI service runs the same command with the token from its secret store.
Yes. The agent is defined in the app's code, with its model, instructions and tools, and ships in the same deploy. Any function or schedule in the app can call it, and the model key is managed by Helix rather than sitting in the code.
Yes. Choose Restore on an earlier deployment in the project's Deployments tab. Helix keeps the deployment before the live one for as long as it holds that spot, and any other deployment for 30 days. Helix rebuilds that deployment's source and ships it as a new deployment, which takes about as long as any deploy. If the rebuild fails, the version that was live keeps serving. A restore brings back code, not data: what the app has stored stays as the newer version left it.
Add an approval gate on the deploy path for apps that warrant it, and let low-risk apps flow straight through. Control scales with the stakes instead of blocking everything.
See how an app or agent goes from an AI assistant to a governed production deploy.
Thanks, keep an eye on your inbox for an invite.
Want to talk to someone first? Contact us
