This is a sequencing checklist for a first public launch. It separates decisions that can be verified before launch from issues that can only be measured under controlled load. It does not establish a survival rate or claim that this order causes a commercial outcome.
This is the seven-day order used in the FiveMCoach server-owner path. It is an unmeasured operating method: use the checks, record the result, and change the timing when your stack requires it.
Treat compatibility, policies, community setup, and a controlled test as pre-launch gates. Passing them removes known blockers; it does not guarantee retention, revenue, or server longevity.
Day 1, Decide what the server is, then buy the VPS
Before you touch a terminal, write three sentences:
- Who is this server for? (Age range, RP seriousness level, language.)
- What's the one-sentence pitch you'll give a stranger?
- Which alternatives will a player compare it with in your language?
If those three sentences do not exist, treat the concept as an open planning dependency before committing to infrastructure.
Once they exist, document the expected region, player test, framework, resources, and database workload. Compare current provider quotes and record the assumptions behind the shortlist. VIP members can bring that shortlist and measured server requirements to a private review before committing to a plan.
Day 2, Boot FXServer and txAdmin
First, generate a free server license key from the Cfx.re Portal (portal.cfx.re), which replaced the old Keymaster; you need a key even for a local test boot. Then follow the official txAdmin startup instructions: run FXServer.exe on Windows or run.sh on Linux without a +exec argument to start txAdmin monitor mode. txAdmin is bundled with FXServer; it is not a separate download.
Open the address printed by the server and finish the setup wizard. On a remote VPS, localhost in your laptop's browser means your laptop, not the VPS. Use the provider's documented administrator access method or your existing secure connection to the server. Keep access restricted to the administrators who need it. Read the server.cfg lesson before changing the game-server configuration.
Reaching the panel proves only that the panel is reachable. Complete the wizard, start the selected recipe, and confirm that a test player can connect and spawn. Record unresolved startup errors. Restart the test server and repeat the connection before marking this stage passed.
Day 3, Pick and install the framework
This decision affects script compatibility, configuration, data, and support work. See the full ESX vs QBCore vs QBox comparison for the decision tree. Inventory the scripts, bridges, database changes, and team knowledge you require, then verify each dependency against the current maintainer and vendor documentation before choosing.
Install the framework, start the server, connect with your Cfx account, and run the written smoke test. If that gate fails, record and resolve the blocker before moving to dependent checks; the day labels are sequencing aids, not evidence of completion time.
Day 4, Validate the core script stack
This checklist uses eight example functions: inventory, housing, phone, dispatch, garage, jobs, core HUD, and money or banking. Your stack may use fewer, more, or different resources. The test is whether every selected dependency and shared data contract works together.
Functions to evaluate for a QBCore stack:
- Inventory, verify one candidate against the current framework, database, phone, housing, and permission requirements.
- Housing, compare the documented framework, inventory, database, and phone integrations before choosing.
- Phone, verify the framework, inventory, job, and database integration against a test copy of your stack.
- Dispatch, verify job permissions, alerts, locations, and failure states in the same test stack.
Use this stage to install the stack, map shared tables, and test with a controlled group. Record unresolved console errors and do not mark the compatibility gate as passed while they remain reproducible.
Day 5, Tebex store, branding, rules
If the server will monetize, configure only packages allowed by the current Cfx.re and Tebex rules. Record each benefit, price, delivery test, refund and support boundary, and the branding or screenshots the package uses. This is a completeness check, not a conversion promise.
Before launch, verify that the rules, community onboarding, screenshots, and any store packages are complete and compliant. The server-owner path treats that record as a required launch milestone.
Day 6, Soft launch to a small audience
Not a public launch. Invite a controlled group that your team can observe and support. Give them a test brief, watch what breaks, record the conditions, and verify each fix.
The soft launch is the stress test. If the measured load fails, do not increase it for public launch. Correct the bottleneck, repeat the same test, and keep the before-and-after evidence.
Write the acceptance record before inviting testers
Use fictional test accounts and a backed-up test database. Record the artifact, framework and resource versions, test-player count, owner and timestamp for each check. Complete this test brief on your own stack; no result is assumed.
- Join and return: connect with a new test character, complete the intended first activity, reconnect, and confirm the expected character state persists.
- One economy loop: earn the configured amount, buy one item, then try with insufficient funds. Check the intended balance and inventory after each action and after reconnecting.
- Permissions: confirm a normal player cannot perform the staff-only actions being tested. Check authorized staff can use them without granting broader access to everyone.
- Recovery: restore a backup into a separate test instance and confirm its recorded state. A backup file existing is not evidence that a restore works. Record the rollback steps and who will perform them before opening the public server.
- Load and errors: repeat the same player actions with the controlled group, record any hitches or client freezes, and follow the lag diagnosis guide for captures. A quiet empty server does not establish capacity.
Mark each check passed, failed or untested with an expected and actual result. Repeat failed checks after a fix. Extend the schedule while required checks remain failed or untested; seven days is a planning sequence, not a deadline that overrides the evidence.
Day 7, Public launch, then iterate
Open the server to the FiveM server list. Open the Tebex store. Post in the relevant communities. Stay available during the opening period so errors, onboarding friction, and support requests are recorded while they can still be reproduced.
After Day 7, replace the launch checklist with an operating cadence: measure onboarding, stability, support load, and return behavior. That is the next playbook.
What we'd change with VIP or Enterprise support
VIP can review the evidence from the setup, compatibility, and controlled-load gates. Enterprise is for a qualified implementation scope when the team, responsibilities, and acceptance checks are clear.
If the stack audit requires hands-on implementation beyond guidance, apply through the Enterprise track.
