Skip to main content
Deploy applies a Version captured on one server to a different server, repeatedly, as a managed relationship rather than a one-off copy. Two sentences govern everything on this page:
DEV describes desired state. PROD owns target identity. A deployment may destroy only what that deployment can prove it owns.

​
The deployment stream

A deployment is a long-lived relationship between one source installation and this server, for one map, over a defined scope.
​
required
The other Vetra installation this deployment accepts Versions from. It cannot be this one: a Version captured here already names local identities, and deploying it would create a second set of objects for all of them. Use Restore for a local Version.
​
required
A deployment applies to one map.
​
groups and objects
Which groups and standalone objects this deployment is entitled to touch at all. Up to 1024 groups. The scope is stored, immutable and shown in every plan.
​
grows as you deploy
The committed source-to-target id map. This is the definition of ownership: the deployment owns a production object if and only if that object appears as a target in this mapping.
Nothing else decides ownership. Not a model, not a position, not group membership, not a numeric id range, not an adapter.
A source id that is not in the mapping resolves to nothing, never to itself. Map creation ids and DarkRP row ids are numbered from the same 1 on both servers, so a fall-through would address a real production object that has nothing to do with the one being deployed.

​
The workflow

1

Get the Version onto the production server

Either export a package on DEV and import it on PROD (Export and import), or use Remote Deploy to hand it over through Vetra.
2

Create a deployment

On the production server, open Deploy and press New deployment. Name it, pick the source installation, the map and the scope.
3

Plan

Blueprints computes one comparison:
Every operation is attributed to a cause, so you can read why each change is proposed: the source moved, production drifted, or both.
4

Acknowledge what needs acknowledging

Some situations block the plan until you say, explicitly, that you understand them. They are listed below.
5

Hold anything you do not want touched

A hold removes an object’s operations from this run entirely. Holds are part of the plan’s fingerprint, so a plan reviewed with a hold cannot be applied without it.
6

Deploy

The run is journalled. Before anything destructive, a scoped recovery capture is taken, exactly as a restore does. Afterwards the result is verified by capturing again and comparing.

​
Acknowledgements

An object this deployment owns has been changed on the production server since the last run. Deploying will overwrite that change. The plan reports every drifted object rather than summarising the count.This is the one that deserves the most attention, because the thing being overwritten is on a server you are not sitting at and cannot see out of the window.
The source Version was captured in a different server session on DEV, and objects this deployment manages are not in it under any identity it recognises, because a restart there reissues session-scoped ids.Continuing removes those objects here and rebuilds whatever the new Version contains, with new identities. Nothing is matched by position, model or name. That refusal to guess is the point.
A group named in the scope is not in the source Version.
The pinned baseline Version could not be read, so every difference is reported as production drift rather than being attributed to a source change. The plan still protects you; it just cannot tell you why each change appeared. Re-import the Version, or acknowledge and continue.

​
Plan staleness

The plan is fingerprinted over the source Version, the baseline, the map, the scope, your acknowledgements, your holds and the live adapter list. That last part matters: reloading or updating an adapter can change what every preflight answer would be, so a plan computed before an adapter update is never applied after one.

​
Recovery

A deployment run writes a scoped recovery capture before it becomes destructive, and keeps a journal. If a run is interrupted, that is durable state: the next destructive entry point sees it and blocks rather than planning against a world in an unknown intermediate state. Nothing about a deployment is decided by looking at the world and guessing what happened.

​
Where deployments live