Also, is there a good way to go from a local automation and move that to the cloud/openhands enterprise? What is the suggested process for that?

I think for this one you would need to have an agent recreate it. You could download the tarball and provide it to the agent to help. But the API surface could be different so I don't know if a direct copy would be the best option.

Yea, they would really like to build an automation, make sure its running locally and then push that automation into OHE/Cloud easily. Right now when they have tried it, it hasn't worked well for them.

But the API surface could be different

I wonder. I don’t think it should be…

🐾 On Rajiv's "can you directly move tarballs local → OHE?" — short version: You can move the tarball (it's just the code), but that doesn't move the automation. An automation is two things: a definition row in the service's DB (schedule, entrypoint, model, trigger) + the code tarball in a file store. Local uses the local filesystem; cloud/OHE uses gcs/s3 — so

tarball_path

, the DB row, secrets and org identity are all per-deployment. Same automation service both sides (so it's not an API-surface mismatch, Engel's right there) — what doesn't travel is the deployment-scoped state. So: carry the code, but re-register on the target. It's mechanical; an agent or a small script does it. The cleaner path is John-Mason's: keep the smarts in a git-backed plugin, not in the automation. Then "move to cloud" = create the same thin automation (schedule + same plugin ref) on OHE and it pulls the code from git. Nothing to transfer — and it answers the source-control/backup question too. Wrote it up with the exact steps + a diagram: https://enyst.github.io/arch/automation-local-to-cloud.html