Reviewing & Going Live

myRP.build loads each generation live on the server it's pointed at — it refreshes and ensures the resource immediately, and adds it to server.cfg so it persists across restarts. That's the feature, but it means where you point the app matters.

Build against a dev server, promote to production

If you point myRP.build at your production server, every generation goes straight onto the live server in front of players — including half-formed attempts while you iterate.

The safer workflow:

1. Point the app at a development/test server (see Pointing at Your Server).
2. Generate, iterate, and test there.
3. Once a resource is right, copy that resource folder to your production [local]/ and ensure it there.

Review before it's live

Generations are server-authoritative by default — money, items, and state are validated on the server, so clients can't bypass them. Still, give each resource a quick read before it faces players:

• config.lua — confirm prices, coordinates, cooldowns, and item names match what you intended.
• Permissions — check any "who can use this" gating is what you want.
• server.lua — skim the authoritative logic (the part that grants money/items) for anything surprising.

Safety nets

• Auto-backup: before overwriting an existing resource, myRP.build snapshots the previous version, so a regeneration can be undone. That covers app-driven changes.
• Version resources/[local]/ with git. A commit per working resource gives you a full history and a second way to roll back — independent of the app's backup.
• Keep the ox stack current. myRP.build builds against the latest Overextended releases; if your server runs much older ox_core/ox_lib, a generated resource may expect newer exports. Update the ox stack if a resource references something your version doesn't have.

If a resource doesn't behave after going live, work through Troubleshooting.