Skip to main content
Remote Deploy does what export and import does, without you moving a file: your development server uploads the package to Vetra, the production server collects it, plans against its own world, and applies it once you approve.
Remote Deploy is optional. Every Version can always be exported to a file, transferred by any means you like, and imported on the other server without the Vetra service being involved. See Export and import.
You drive it from inside Garry’s Mod, on the Remote Deploy screen. There is no web dashboard to sign into, and no customer account to create.

​
Two routes to the same outcome

Both end at the same place: a deployment on the production server, planned against that server’s own world and applied by it.

​
What you need

  • Both servers activated on the same licence.
  • Outbound HTTPS from both servers, while you are using it. A cached licence is enough to keep local Blueprints working offline, but Remote Deploy is a live operation and needs the connection at the time.
  • The same map on both servers. Remote deployment is same-map.

​
The flow

1

Prepare, on the development server

Pick a Version and a target. Blueprints exports the Version as a package and uploads it to Vetra.Transfer progress is shown in real bytes. Where Blueprints has no real number, it shows the phase instead. There is no invented percentage anywhere in this screen, because an invented number during a destructive operation is a lie.
2

The target picks it up

The production server polls Vetra on its own schedule, downloads the package, checks it against its digest, and plans against a fresh capture of its own world.
3

Approve

The plan comes back to you: what will be created, moved, conformed and destroyed on the target server, plus anything needing an acknowledgement.The wording here names the target server in every sentence, deliberately. “12 objects will be overwritten” reads very differently when the objects are on a machine you are not sitting at.Nothing on the target has been modified at this point.
4

Apply

The target server takes a scoped recovery capture, applies the plan, and verifies the result against the Version.

​
Where authority actually sits

The screen you are reading the plan on has no authority. It displays a plan the target server computed and Vetra relayed, and sends back the fingerprint of what it displayed.
Your own server re-fetches the current plan from Vetra before relaying your approval, and the target re-plans from a fresh capture before it writes anything. Approving one plan and having a different one applied is not a thing that can happen. The production server always decides what happens to its own world.

​
States

​
When something fails

Failures come back in a closed vocabulary with a sentence you can act on. You will never see a stack trace, a database error or an internal code.

​
What Vetra stores

When you use Remote Deploy, the package you selected is uploaded to and stored on the Vetra service, together with a record of that deployment. Nothing else about your server is sent, and nothing is uploaded unless you start a deployment. Packages your deployment history references are retained, and not deleted on a schedule. Redeploying an older Version and rolling back are the same operation, and both need the original bytes; a support question about what you deployed is only answerable while the package still exists. Uploads that were started and never completed are cleaned up. If you want a stored package removed, ask. Full detail in Where your work is stored.