# SCP: Secret Laboratory Server Hosting - everything RE:NODE has published > A SCP: Secret Laboratory server on RE:NODE: plans, how the panel runs it, and every tutorial RE:NODE has published about it. Generated from https://www.renode.space/game-servers/scp-secret-laboratory, the live catalogue, the deploy docs, the panel guides and the RE:NODE blog. English. Source of truth for anything that changes: https://www.renode.space/game-servers/scp-secret-laboratory. Contents: what it is, plans and prices, panel how-to, tutorials, rules for the assistant. ## What it is SCP: Secret Laboratory servers, plugin-ready. Run !verify in the console once and your server appears in the public browser. - Genres: Action, Casual, Indie, RPG - Developer: Northwood Studios - Released: 29 Dec, 2017 - Steam: https://store.steampowered.com/app/700330/ ### What comes with every SCP: Secret Laboratory server - Configured before you see it: The install runs, the configuration is written and the server starts. No first-boot checklist, and nothing left on a default password shared with every other SCP: Secret Laboratory server on the internet. - The real console: Live output, command input and the server's own logs - not a filtered summary. Web-server noise is folded behind a counter you can switch off. - Files and SFTP: A full file manager with an editor, plus SFTP credentials. Upload mods, edit configs, pull a world down to your machine. - 2-2 backup slots: Taken on demand or on a schedule, restored with a button. Deleting a server takes its backups with it, on purpose. - 2 ports allocated: Add and remove ports yourself from the Network tab, including the query and RCON ports where the game wants them. - People on the same server: Invite friends or staff with granular permissions - console only, files only, no billing - through subusers, roles and teams. ### Which SCP: Secret Laboratory plan do you need? Memory is what decides whether a server holds together, so start there. The Starter tier gives 4 GB and 1 vCPU, which suits a private group. The Advanced tier at 6 GB is where most public servers sit, and Premium at 10 GB exists for the servers that stay full. Storage matters more than people expect once mods and backups are involved - plans here run from 15 GB to 40 GB of NVMe. Moving up or down a tier later does not rebuild your world; it changes the limits on the container you already have. If you are not sure, take the middle tier. It is cheaper to move up after a busy weekend than to spend one explaining lag to your players. More game servers: https://www.renode.space/ai/game-servers.md ### General questions ### Getting started **How quickly is my server ready?** Game, app, web and database servers are created the moment payment clears, usually inside a minute. The game or runtime is installed and started for you, and the console is live in your browser while it happens. VDS and dedicated servers are prepared by hand and delivered within 24 hours. **Do I need to configure anything before it works?** No. The install runs, the configuration is written, and admin passwords are generated for your server rather than shared with everybody else's. The exception is four games whose publisher issues a credential to a person - those say so on the shop before you pay, and ask for it on a Setup tab afterwards. **Which games need a key from me?** Counter-Strike 2 needs a Steam game-server token, Don't Starve Together a Klei cluster token, FiveM a Cfx.re licence, and DayZ, Project Zomboid, 7 Days to Die, Arma 3 and Unturned need a Steam account or token of your own. We cannot create any of them and we never share one between customers. Your server is built immediately and the installation waits until you paste yours in. **Can I try before buying?** There is no free tier. The entry plans start at $1.50 a month precisely so that trying something costs about as much as a coffee. **Can Claude or ChatGPT set my project up?** Yes, and the panel gives it what it needs. On a server's Console tab, pick a purpose and press Connect AI: the panel copies a private link with the runtime, the port the code must read from SERVER_PORT, the code path, the GitHub branch, the databases and the limits. Paste it into Claude, ChatGPT or any assistant that can open links; the same link followed by /mcp works as an MCP server URL. It stops by itself after 7 days unused. You can also connect Claude, or any MCP client, to your whole account at https://panel.renode.space/api/client/mcp. Linked repositories get a pre-flight check that shows what will break before a deploy, no AI needed. No password or token is ever shown to the assistant - the AI setup page explains it all. ### Running the server **Do I get full file access?** Yes - a complete file manager with an in-browser editor, plus SFTP credentials. There is no plan on which the file manager is disabled or read-only. **Can I install mods and plugins?** Yes. Upload them through the file manager or SFTP, or use the game's own workshop support where it has any. Nothing here whitelists which mods you are allowed to run. **Can other people help me run it?** Yes. Invite subusers with granular permissions - console only, files only, no billing - or build a team with a role and grant it access to several servers at once. Permissions are a union, so nobody loses access they were given elsewhere. **What happens if my server runs out of memory?** New servers are configured so the kernel stops the container and it restarts clean, rather than swapping and dragging the whole machine down. If a server restarts repeatedly we warn you on the server page and open a support ticket before anything is suspended - you get told twice before it stops. **Is the CPU limit a hard limit?** Yes, and it cannot be breached: the container is throttled to the share you bought. A server sitting at 100% is slow, not broken, and is never suspended for it. ### Backups and safety **Are backups included?** Every plan carries backup slots - two on the entry tiers, more further up. Take them on demand or on a schedule, and restore with a button rather than a support ticket. **Where are backups stored?** Off the machine they protect. A backup sitting on the same disk as the thing it is insuring covers you deleting your world and covers nothing at all about the disk failing. **What happens to my backups if I cancel?** Deleting a server deletes its backups with it, deliberately and including locked ones. Download anything you want to keep first - the panel lets you. ### Billing **How do I pay?** PayPal, card, your wallet balance, or bank transfer. Every method produces a proper invoice you can download or print, with our details and the bank account on it while it is unpaid. **Can I pay in Georgian lari?** The panel displays every figure in lari at the National Bank of Georgia's published rate, marks converted figures as approximate, and always shows the amount that will actually be charged. Invoices stay in the currency they were raised in, because an invoice is a demand for a specific amount. **What happens when my subscription is due?** An invoice is raised and emailed to you seven days before expiry, and again on the day. Paying it settles that same document rather than raising a second one. **Can I upgrade or downgrade later?** Yes, and it does not rebuild anything. Changing plan changes the limits on the container you already have - your world, files and database stay exactly where they are. **Do you offer refunds?** There is no automatic refund button. If a server cannot do what it was sold to do, open a ticket and we will sort it out - including refunding you. We would rather fix the plan than argue about the policy. ### Support and the honest bits **How do I get help?** Open a ticket from the panel - it reaches every member of staff and every administrator, not a queue aimed at nobody in particular. Attach a screenshot if it helps; attachments are private to your ticket rather than sitting at a guessable public URL. Discord is there for faster, less formal questions. **Where are the servers?** Germany, on hardware we run. That is one location: if you need players in another region on a low ping, say so before buying rather than after. **Is there an uptime guarantee?** We measure node availability every five minutes and report it in the panel rather than printing a number with four decimal places we have not earned. If something is down you will usually hear it from us first. **Who actually runs this?** A small team that writes the panel, the shop and the automation itself. When something is wrong the fix is a code change, which is why the list of things wrong keeps getting shorter. ## Plans and prices Read from the live catalogue at 2026-10-15 02:50 UTC. Prices are in US dollars per month; checkout also takes Georgian lari and bills for 1, 3, 6, 12 or 24 months. Prices change - re-check on https://www.renode.space/game-servers/scp-secret-laboratory or in the panel shop at https://panel.renode.space before quoting one. | Plan | Price / month | Memory | CPU | NVMe disk | Databases | Backups | Ports | |---|---|---|---|---|---|---|---| | Starter | $8 | 4 GB | 1 vCPU | 15 GB | 1 | 2 | 2 | | Standard | $11 | 5 GB | 1.5 vCPU | 20 GB | 1 | 2 | 2 | | Advanced | $14 | 6 GB | 2 vCPU | 25 GB | 1 | 2 | 2 | | Pro | $18 | 8 GB | 2.5 vCPU | 30 GB | 1 | 2 | 2 | | Premium | $23 | 10 GB | 3 vCPU | 40 GB | 1 | 2 | 2 | ## Panel how-to From the panel guides at https://www.renode.space/guides. ### Ordering a server Ordering takes about a minute and happens in three screens: find what you want to run, pick a plan, and pay. Pay by card or PayPal and the server is set up the moment the payment goes through - you can watch it install in its console. - Takes: About a minute - Pay with: Card, PayPal or bank transfer - Billed for: 1, 3, 6, 12 or 24 months - Prices in: US dollars or Georgian lari Open the shop and find what you want to run: 1. Sign in to the panel and open the shop. The tabs along the top are the product lines: VDS, Game Servers, App Hosting, Web Hosting and Databases. 2. Find your game - there is a search box - and press View plans. The card already shows the lowest price and the range of memory on offer. Compare the plans and pick one: 3. Every plan lists its memory, CPU and NVMe storage, roughly how many players it suits, and what is included - updates, backup slots, file and SFTP access. 4. Press Get Started on the one you want. Not sure? Start smaller: you can move to a bigger plan later without losing your world. Choose how long, then pay: 5. Pick a billing period - 1, 3, 6, 12 or 24 months. The total for the whole period is shown before you pay, so there are no surprises. 6. Pay with PayPal, or press Debit or Credit Card - paying by card does not need a PayPal account. The server is created as soon as the payment completes. Paying by bank transfer instead: Prefer to pay from your bank? Choose bank transfer at checkout. The server is set up once the payment arrives, usually the next working day. 1. Switch the payment tab to Bank transfer. The account details for Bank of Georgia and TBC Bank appear, each with a Copy button. 2. Press Order & get invoice, then pay that invoice from your banking app, quoting the reference on it. After you pay: - The server appears under My Servers and installs itself. Open it to watch the install in the console. - Your orders, invoices and subscriptions are under Finances in the side menu. - Stuck at any step? Open Support in the side menu and raise a ticket. ### The console Live output, a command line, power controls and the resource graphs. It is the server's own output rather than a filtered summary - if the game prints it, you see it. - Start, stop, restart and kill, with the current state always visible. - Command history with the arrow keys, and tab completion for common commands. - Web-server noise - the internet knocking on doors that are not there - is folded behind a count you can switch off. A real error always prints. - Graphs for memory, CPU and disk against your limits, so whether it is the plan or the mod is answerable. ### Files and SFTP A complete file manager with an editor in the browser, plus SFTP credentials for the tools you already use. Upload a modpack, fix a config, pull a world down to your machine. - Drag files in, or upload a folder. Archives can be unpacked in place. - Edit any text file with syntax highlighting and save without downloading it. - PDFs and images preview in the panel rather than downloading first. - SFTP on the same credentials - use FileZilla, WinSCP or your editor's remote mode. ### Backups Take one before you try something. Restore it when the something goes wrong. Lock the ones that matter so they are not rotated away. - Slots on every plan - two on the entry tiers, more further up. - Take one on demand, or on a schedule you set. - Download any backup to your own machine. > Important: Deleting a server deletes its backups, including the locked ones. A lock stops you removing a backup by accident; it is not a claim on the disk after the server is gone. Download what you want to keep before you cancel. ### Subusers, roles and teams Give somebody the console without giving them your files, or the files without your billing. Three separate ideas, kept apart deliberately. - A role holds permissions - what may be done. - A team holds people. - A grant joins a team to a server with a role, so adding a moderator to the team gives them the same access everywhere at once. - Invite by link, by a join code, or by email address - and require approval on the codes if you would rather vet people. - Access can be time-boxed, and expiry stops working immediately rather than overnight. ### Scheduled tasks Restart nightly, back up before the restart, announce it to players first. Tasks run in order with delays between them, so a schedule can be a small routine rather than one action. - Send a console command - a warning to players, a save, a world flush. - Take a backup. - Power actions: start, stop, restart. ### Games that need a key from you A few games want a credential their publisher issues to a person - a Steam game-server token, a Steam account that owns the server files, a Klei cluster token, a Cfx.re licence. We cannot create one and we never share one between customers. > Note: Those games say so on the shop before you pay. Your server is built immediately, and the game installation is held until you paste the value into a Setup tab, because installing without it produces a server with no game files in it and no explanation. ## Tutorials 2 posts, newest first. Each one follows in full after the list. - [SCP: Secret Laboratory EXILED and LabAPI plugins](https://www.renode.space/blog/scp-secret-laboratory-exiled-plugins) (2026-10-07): Install and manage SCP:SL server plugins: EXILED and LabAPI folders, per-port YAML configs, permissions.yml, reload commands and surviving game updates. - [SCP: Secret Laboratory server and plugins](https://www.renode.space/blog/scp-secret-laboratory-server-guide) (2026-09-21): Run an SCP: Secret Laboratory server: LocalAdmin, config_gameplay.txt, Remote Admin roles and permissions, verification, and plugins on LabAPI or EXILED. --- ### SCP: Secret Laboratory EXILED and LabAPI plugins Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/scp-secret-laboratory-exiled-plugins An SCP: Secret Laboratory server runs plugins through LabAPI, Northwood's official framework, which ships inside every server build. EXILED, the larger community framework, is now itself a LabAPI plugin, so a modern server can run native LabAPI plugins and EXILED plugins side by side. Plugins are `.dll` files dropped into per-port or global folders in the server's app data, each one writes a YAML config on first start, and permissions for plugin commands come from a `permissions.yml` keyed by your Remote Admin group names. Almost every plugin problem is one of four things: the plugin was built for a different game or framework version, it is in the wrong folder, its YAML did not parse, or the permission group name does not match a Remote Admin group exactly. This guide goes through each of them in the order you will meet them. For the server itself - LocalAdmin, `config_gameplay.txt`, Remote Admin roles and verification - see the [SCP: Secret Laboratory server guide](https://www.renode.space/blog/scp-secret-laboratory-server-guide). This post starts where that one stops. #### How LabAPI and EXILED fit together ```diagram title: How plugins load on a current SCP:SL server server = SCP:SL server | LabAPI built in labapi = LabAPI plugins | LabAPI/plugins loader = Exiled Loader | a LabAPI plugin exiled = EXILED plugins | EXILED/Plugins configs = YAML configs | per port server -> labapi labapi -> loader loader -> exiled labapi --> configs exiled --> configs ``` LabAPI is the base layer. Its folders sit under the game's app data directory - `~/.config/SCP Secret Laboratory/` on Linux, `%AppData%\SCP Secret Laboratory\` on Windows - in a `LabAPI` folder with `plugins`, `dependencies` and `configs` beneath it. By default it loads from a `global` folder and from a folder named after the server's port, so one machine can run several servers with different plugin sets. EXILED sits on top. Its loader is a LabAPI plugin, and once loaded it reads its own tree, an `EXILED` folder in the same app data root. That layering has one consequence worth remembering: when a game update bumps LabAPI's major version, the whole EXILED stack waits on an EXILED update, not just one plugin. Which to choose is mostly decided by the plugins you want. A plugin built for LabAPI goes in LabAPI's folders; a plugin built for EXILED needs EXILED installed and goes in EXILED's folders. A plugin page that says neither is probably out of date - older plugins targeted the retired NWAPI, and those do not load on current builds. #### Folders and files, side by side | Purpose | LabAPI | EXILED | | --- | --- | --- | | Plugin DLLs | `LabAPI/plugins/global/` or `LabAPI/plugins//` | `EXILED/Plugins/` | | Shared libraries | `LabAPI/dependencies/global/` or `/` | `EXILED/Plugins/dependencies/` | | Plugin configs | `LabAPI/configs///` | `EXILED/Configs/Plugins//.yml` | | Translations | Plugin-specific | `EXILED/Configs/Translations//.yml` | | Permissions | `LabAPI/configs/permissions.yml` | `EXILED/Configs/permissions.yml` | | Remote Admin log | - | `EXILED/-RemoteAdminLog.txt` | Two notes on that table. LabAPI also writes a `properties.yml` beside each plugin's config, holding `IsEnabled` and an `UnsupportedLoading` override, which is how you switch one plugin off without deleting it. And EXILED's config layout depends on its loader's `ConfigType` setting: the current default is `Separated`, one file per plugin per port as shown above, while `Default` puts every plugin into a single `EXILED/Configs/-config.yml` with a matching `-translations.yml`. The console command `econfig merge` and `econfig split` convert between the two. Older guides assume the single-file layout; if you cannot find a config where a guide says it is, this is why. #### Installing EXILED EXILED is installed with its own installer, `Exiled.Installer-Linux` or `Exiled.Installer-Win.exe`, which downloads a release from GitHub and unpacks it into the right places: ```bash $ ./Exiled.Installer-Linux --path /home/container \ --appdata /home/container/.config --exiled /home/container/.config ``` | Option | What it does | | --- | --- | | `--path` | The SCP:SL server folder | | `--appdata` | Forces the app data root. Needed in containers where the process runs as a different user | | `--exiled` | Where the `EXILED` folder goes | | `--target-version` | Installs a specific release instead of the latest | | `--get-versions` | Lists available releases | | `--pre-releases` | Allows pre-release builds | `--appdata` is the option that matters on hosted servers. The server reads the app data folder of the user it runs as; if the installer writes somewhere else, EXILED is installed and never loads. If the console shows no EXILED banner on start, check that the paths the installer printed match where the server keeps its `config` folder. The loader has its own settings, kept in LabAPI's configs folder under the loader's plugin name. Three of them deserve a decision rather than a default: | Key | Default | Recommendation | | --- | --- | --- | | `EnableAutoUpdates` | `true` | Turn off on a live server. Update deliberately, not mid-week | | `ShouldLoadOutdatedPlugins` | `true` | Fine while it works; the first suspect when something breaks | | `ShouldLoadOutdatedExiled` | `false` | Leave it | Automatic updates are convenient on a test server and a liability on a busy one. An EXILED release that lands while plugins are still built against the previous one is exactly how a server breaks with nobody having touched it. #### Installing and configuring a plugin The procedure is the same for both frameworks: 1. Check the plugin's page for the framework and the game version it was built against. If either does not match, stop. 2. Stop the server. 3. Put the DLL in the plugin folder and any listed dependencies in the dependencies folder. Global folders apply to every port; port folders only to that server. 4. Start the server once. The plugin writes its default config. 5. Stop it, edit the config, start again - or edit and use a reload command. A typical EXILED plugin config is plain YAML with two keys every plugin has, `is_enabled` and `debug`, followed by its own options: EXILED/Configs/Plugins/example_plugin/7777.yml: ```yaml is_enabled: true debug: false # Message shown to a player on join welcome_message: 'Welcome to the Site-02 night shift' broadcast_duration: 6 allowed_roles: - ClassD - Scientist ``` YAML is unforgiving in specific ways. Indentation is spaces, never tabs. A value containing a colon, a hash or a leading special character needs quotes, and EXILED writes strings single-quoted by default, so keep that style. Lists are a dash and a space at the start of the line at the right depth. When a file does not parse, the plugin either loads with defaults or does not load at all, and the error is in the console at start - [game server config file formats](https://www.renode.space/blog/game-server-config-file-formats) covers the YAML traps in more detail. > [!WARNING] > Keep a copy of every config before you edit it. When EXILED cannot read a config it may regenerate defaults, and a plugin that silently reverts to its default settings is much harder to notice than one that fails to load. LabAPI plugin configs work the same way under `LabAPI/configs///`, usually as `config.yml`, with field names chosen by the plugin's author. ##### Reloading without a restart Restarting mid-round kicks everyone, so both frameworks can reload from the server console or Remote Admin: | Command | Effect | | --- | --- | | `labapi reload configs` | Reloads configs for all LabAPI plugins. Short form `lab r c` | | `reload configs` | Reloads EXILED plugin configs | | `reload translations` | Reloads EXILED translations | | `reload permissions` | Reloads EXILED `permissions.yml` | | `reload plugins` | Reloads EXILED plugins. Use with care | | `reload gameplay` / `reload remoteadmin` | Reloads the game's own config files | | `pluginmanager show` | Lists EXILED plugins and their state | | `pluginmanager enable` / `disable` | Switches an EXILED plugin on or off | Config reloads are safe for settings a plugin reads when it needs them. Settings read once at start - a list of custom roles, a database connection - may still need a restart. When a reload seems to do nothing, restart between rounds before assuming the setting is broken. #### Permissions for plugin commands Remote Admin permissions decide what the game's own commands allow. Plugin commands check a second layer: framework permissions, which are strings such as `myplugin.kick` granted to groups. EXILED's `permissions.yml` is keyed by Remote Admin group name, plus a special `user` group for everybody without one: EXILED/Configs/permissions.yml: ```yaml user: default: true inheritance: [] permissions: [] moderator: inheritance: [] permissions: - adminplugin.kick - adminplugin.mute admin: inheritance: - moderator permissions: - adminplugin.* owner: inheritance: [] permissions: - .* ``` The rules that trip people up: - **Group names must exactly match the role names in `config_remoteadmin.txt`.** A group that matches nothing is ignored with a warning in the console, which scrolls past at start. - **Every group needs both `inheritance` and `permissions`**, even if empty. Leaving one out makes the whole file fail to parse, not just that group. - **`default: true` marks the group used for players with no Remote Admin role.** Exactly one group should have it. - **Wildcards.** `adminplugin.*` grants everything under that prefix; `.*` grants everything, and belongs only on the owner group. - **Inheritance is one-way.** `admin` inheriting `moderator` gets moderator's permissions, not the other way round. After editing, run `reload permissions` or the permissions command's own reload. LabAPI's equivalent is `LabAPI/configs/permissions.yml`, also keyed by Remote Admin group name, with a `default` group for everyone else; `labapi permissions` shows what you hold. Grant plugin permissions as narrowly as Remote Admin roles - a moderator with `.*` is an owner in everything but name. [Subusers and least privilege](https://www.renode.space/blog/subusers-and-least-privilege) makes the same argument for panel access. #### Choosing plugins The official plugin directory, which LocalAdmin's `p` commands can install from, is the safest source. Beyond that, plugins come from GitHub releases. Some categories and what to watch in each: | Category | Examples | Watch for | | --- | --- | --- | | Moderation and bans | CedMod, AdminTools | Web panels need outbound access and their own accounts | | Custom roles and items | UncomplicatedCustomRoles, EXILED's own CustomRoles and CustomItems | Balance, and configs that are long and fragile | | Statistics and Discord | SCPStats | API keys, privacy of player data | | Round and respawn tweaks | Respawn timers, team balance | Interaction with other gameplay plugins | | Fun and event plugins | Event modes, cosmetic effects | Usually the first to break after an update | EXILED installs `Exiled.CustomItems`, `Exiled.CustomRoles`, `Exiled.Events` and `Exiled.Permissions` as part of itself. Other plugins that depend on them do not need them installed separately. Fewer is better. Every gameplay plugin is another hook into the same events, and two plugins changing the same thing - spawn waves, role assignment, item pickup - interact in ways neither author tested. Add plugins one at a time and play a round between additions. Any plugin runs with the server's full permissions and sees every player connection. Download from the author's repository or the official directory, never from a reupload in a Discord channel. [Malicious plugins and mods](https://www.renode.space/blog/malicious-plugins-and-mods) covers what a hostile one can do, and [keeping a modded server clean](https://www.renode.space/blog/keeping-a-modded-server-clean) the routine that keeps you out of trouble. #### Surviving game updates SCP: Secret Laboratory ships updates regularly, and a server that updates automatically on restart will pick them up before plugin authors have. The pattern is familiar: the server starts, the log fills with `MissingMethodException` or a refusal to load a plugin built against a different major version, and half your features are gone. A routine that works: 1. **Know what you run.** Keep a list of plugins with versions and source links, next to your config backups. 2. **Pin before patch day.** When Northwood announces an update, decide whether you will run it immediately. A server can sit on the previous build for a few days while plugins catch up, as long as clients can still connect - for a major update they cannot, and you update regardless. 3. **Update frameworks first, then plugins.** LabAPI comes with the game; then EXILED; then each plugin built for the new version. 4. **Leave unsupported loading off.** LabAPI's `LoadUnsupportedPlugins` defaults to `false` so a plugin built for a different major version is refused rather than loaded. A plugin that loads and misbehaves mid-round is worse than one that does not load. 5. **Test before the busy hours.** A second server on another port with the same plugins is cheap - [running a test server beside production](https://www.renode.space/blog/running-a-test-server-beside-production) explains how to keep one honest. On RE:NODE the SCP:SL server's console is LocalAdmin's console with command history, so `reload configs` and `pluginmanager show` are typed where you read the output. The plugin and config folders are reachable in the file manager and over SFTP, and a backup slot taken before every update is the fastest way back to a working set - restoring is one button. The Schedules tab can run a daily restart at a quiet hour, which is also a natural moment to take updates deliberately rather than whenever the server happens to restart. [What to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) has the recovery order. #### Performance Plugins, not players, are what make an SCP:SL server slow. The server targets a fixed tick rate, and every handler on a busy event - player movement, damage, item pickup - runs inside it. EXILED's `tps` command shows the current rate from the console. If it drops with plugins installed and not without, disable plugins one by one with `pluginmanager disable` between rounds until it recovers. A single plugin doing a database call on every damage event can halve the tick rate on a full server. [What tick rate actually means](https://www.renode.space/blog/what-tick-rate-actually-means) explains what players feel when it drops. #### Troubleshooting **No EXILED banner on start.** The loader is not in `LabAPI/plugins/global/` or the port folder, or EXILED was installed into a different app data folder from the one the server reads. Re-run the installer with `--appdata` pointing at the right root. **A plugin is listed but nothing happens.** `is_enabled` is false, its `properties.yml` disables it, or a dependency is missing - the console says which at load. **`MissingMethodException` after an update.** The plugin was built against the previous game or framework version. Update or remove it. **Plugin commands say you lack permission.** The group name in `permissions.yml` does not match the Remote Admin role name, or the file failed to parse because a group lacks `inheritance` or `permissions`. **Config changes revert.** The YAML did not parse and defaults were regenerated. Validate the file, restore your copy, and check the console after the next start. **Config is not where the guide says.** The guide assumes EXILED's single-file layout. Look under `EXILED/Configs/Plugins/` or run `econfig merge`. #### FAQ ##### Do I need EXILED to run plugins? No. LabAPI is built into the server and runs LabAPI plugins with nothing extra installed. You need EXILED only for plugins written for EXILED, which is still a large share of what is available. ##### Can LabAPI and EXILED plugins run at the same time? Yes. EXILED's loader is itself a LabAPI plugin, so both kinds load together. The cost is an extra layer that has to be updated when LabAPI's major version changes. ##### Where do plugin configs go on a server with several ports? LabAPI keeps configs in `LabAPI/configs//`, and EXILED's separated layout writes one file per port inside each plugin's config folder. Plugins in a `global` folder load for every port but still get per-port configs. ##### Why does my permission group not work? The group name must match a role in `config_remoteadmin.txt` exactly, and every group needs both `inheritance` and `permissions` lines. One malformed group stops the whole file loading. ##### Should I let EXILED update itself? Not on a live server. Automatic updates can install a new EXILED before your plugins support it. Update on purpose, after checking each plugin, with a backup taken first. ##### How do I reload a plugin config without restarting? Use `reload configs` for EXILED or `labapi reload configs` for LabAPI, from the server console or Remote Admin. Settings that a plugin only reads at start still need a restart. SCP: Secret Laboratory servers on RE:NODE start at 4 GB with the port allocated, the LocalAdmin console in the browser, and the plugin and config folders reachable in the file manager or over SFTP. Backup slots on every tier mean the plugin set that worked before an update is one restore away. [See SCP:SL plans](https://www.renode.space/game-servers/scp-secret-laboratory) --- ### SCP: Secret Laboratory server and plugins Published 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/scp-secret-laboratory-server-guide The SCP: Secret Laboratory dedicated server is a free SteamCMD download (app id `996560`), it has a native Linux build, it listens on one UDP port, and it runs perfectly well in 4 GB of memory for a twenty-slot server. It is also the most opinionated server in this category: you do not launch the game binary directly, you launch a wrapper called LocalAdmin; the configuration is not in the install folder but in your user profile, split into a folder per port; and the official plugin framework now ships inside the server build, which has quietly changed how every mod guide older than a year works. This covers the whole of it, in the order you will need it. #### What the dedicated server is and what it can do The server is a headless Unity build. It runs one facility, one round at a time, restarts the round when it ends, and holds `max_players` people, which is `20` by default. Sixty is the practical ceiling and the documented maximum for a verified server. The game is balanced around roughly twenty to thirty-five players, and a sixty-slot server plays like a different game rather than a bigger one. What you get out of the box, with no plugins at all: - **Remote Admin**, a real permission system with named roles, badges, kick power and twenty-nine individual permission nodes. - **Bans and whitelists** as plain text files, by user ID and by IP. - **A large gameplay config** covering respawn waves, the warhead, decontamination, friendly fire, stamina, AFK kicking and spawn protection. - **A friendly-fire detector** that will ban team-killers on its own, with four independent detectors and configurable thresholds. - **Geoblocking**, rate limits, pre-authentication challenges and a report webhook for Discord. - **An idle mode** that drops the tick rate to 1 when nobody is connected. What it does not have is a Source-style RCON. Administration happens through the in-game Remote Admin panel, the LocalAdmin console on the machine, and an optional query port that is off by default. Plugins add the rest. #### Requirements and resource usage Northwood publishes one hard number: a verified server needs at least **2 physical cores, 4 GB of memory and 20 GB of storage**. That is a floor, not a recommendation, and it lines up with what a plain twenty-slot server actually uses. | Setup | RAM | CPU | Notes | | --- | --- | --- | --- | | 20 slots, vanilla | 4 GB | 2 cores | The documented minimum and a normal server | | 30-40 slots, vanilla | 5-6 GB | 2-2.5 cores | Comfortable headroom | | 20-30 slots with plugins | 6-8 GB | 2.5-3 cores | Plugins are the variable, not the players | | 60 slots | 8-10 GB | 3 cores | The documented maximum for a verified server | - **CPU**: the round simulation runs on one thread, so single-core clock speed sets your tick rate and core count does not. `server_tickrate` defaults to `60`; if the machine cannot sustain it, the server does not warn you, it just runs behind. - **Disk**: the install is modest and round logs are the thing that grows. LocalAdmin will prune them for you - `delete_old_round_logs` and `round_logs_expiration_days` exist for exactly this. - **Network**: light per player, and the transport is LiteNetLib over UDP. Nothing here needs a fat pipe. The honest sizing answer: if a plugin-heavy server is slow, the plugins are almost always the reason, not the player count. [What tick rate actually means](https://www.renode.space/blog/what-tick-rate-actually-means) explains why the number matters and what a player feels when it drops. #### Installing and starting through LocalAdmin Anonymous SteamCMD, no account, no token: ```bash $ steamcmd +force_install_dir /home/scpsl/server +login anonymous \ +app_update 996560 validate +quit ``` [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained) covers the general form. Inside the install you get the game binary - `SCPSL.x86_64` on Linux, `SCPSL.exe` on Windows - and a wrapper, `LocalAdmin` or `LocalAdmin.exe`. **You start the wrapper, not the game.** LocalAdmin takes the port as its first positional argument, restarts the server when it crashes, keeps the logs, and gives you a console: ```bash $ cd /home/scpsl/server $ ./LocalAdmin 7777 ``` Leave the port off and it asks for one interactively, defaulting to `7777`. On a first run it walks you through a configuration wizard and writes the files described below. You will also want `--acceptEULA` (or the environment variable `ACCEPT_SCPSL_EULA=TRUE`) in anything unattended, and `--config ` if you keep configuration somewhere of your own choosing. > [!WARNING] > On Linux, running LocalAdmin as a plain systemd service with no terminal attached makes it sit at 100% CPU, idle mode or not. It wants a terminal on standard input. Run it under `screen` or `tmux`, or in a container that gives it a TTY. A panel-based host has already solved this; a hand-rolled systemd unit has not. LocalAdmin has its own commands, separate from the game's: `exit`, `restart`, `forcerestart`, `resave`, `help`, and `p` for the built-in plugin manager. It also reads `config/laargs.txt` for extra startup arguments, which is a tidier place for them than a start script. #### Where the config files actually live Not in the install folder. The root is your user profile: | Platform | Root | | --- | --- | | Linux | `~/.config/SCP Secret Laboratory/` | | Windows | `%AppData%\SCP Secret Laboratory\` | Under that root, `config/` holds a folder per port, so one install can run several servers with completely separate settings: ```text config/ config_localadmin_global.txt laargs.txt 7777/ config_gameplay.txt config_remoteadmin.txt config_localadmin.txt config_sharing.txt UserIDBans.txt IPBans.txt UserIDWhitelist.txt UserIDReservedSlots.txt ``` There is one override worth knowing, because nearly every game panel uses it. If a file called `hoster_policy.txt` in the server's working directory contains the line `gamedir_for_configs: true`, the whole root moves to `AppData/` inside the server directory instead of the user profile. That is why a guide's paths may not match what you see in a file manager, and why the answer to "where is my config" on a hosted server is usually "look for an `AppData` folder next to the binary". On RE:NODE you find it in the in-browser file manager or over SFTP, and the in-browser editor will syntax-highlight it. `config_sharing.txt` is the other thing to know about: it decides which folder the ban, mute, whitelist and reserved-slot files are read from, so several ports can share one ban list. Per-port is only the default. There is **no `motd.txt`**. The description players see in the browser comes from `serverinfo_pastebin_id`, which is the ID of a Pastebin paste the server fetches. That catches everybody once. #### config_gameplay.txt, the settings that matter The syntax is `key: value`, one per line, and the space after the colon is required - the parser splits on a colon followed by a space, so `key:value` is silently ignored. That single detail causes more "my setting does nothing" reports than anything else in the file. The file is long. These are the ones that decide what your server is: config_gameplay.txt: ```yaml server_name: Facility 07 max_players: 20 server_tickrate: 60 serverinfo_pastebin_id: 7wV681fT contact_email: admin@example.com friendly_fire: false friendly_fire_multiplier: 0.4 auto_round_restart_time: 10 end_round_on_one_player: false restart_after_rounds: 0 online_mode: true enable_whitelist: false ip_banning: true afk_time: 90 spawn_protect_enabled: false spawn_protect_time: 8 idle_mode_enabled: true idle_mode_time: 5000 idle_mode_tickrate: 1 enable_query: false ``` Grouped by what they do: | Area | Keys | | --- | --- | | Identity | `server_name`, `serverinfo_pastebin_id`, `contact_email`, `max_players` | | Round flow | `auto_round_restart_time`, `end_round_on_one_player`, `restart_after_rounds`, `lobby_waiting_time`, `enable_fast_round_restart` | | Respawns | `minimum_MTF_time_to_spawn` (280), `maximum_MTF_time_to_spawn` (350), `maximum_MTF_respawn_amount` (15), `respawn_tickets_enable` | | Warhead | `warhead_tminus_start_duration` (90), `auto_warhead_start_minutes`, `lock_gates_on_countdown`, `open_doors_on_countdown` | | Decontamination | `disable_decontamination`, `auto_decon_broadcast_enabled` | | Friendly fire | `friendly_fire`, `friendly_fire_multiplier` (0.4), the `ff_detector_*` family | | Access | `online_mode`, `enable_whitelist`, `ip_banning`, `same_account_joining`, `geoblocking_mode` | | Idle and AFK | `idle_mode_enabled`, `idle_mode_time`, `idle_mode_tickrate`, `afk_time`, `constantly_check_afk` | A few notes that save an evening each. `idle_mode_enabled: true` is the setting that makes an empty server cost nothing, dropping it to one tick per second after five seconds with nobody on. The friendly-fire detector is genuinely good and genuinely aggressive - `ff_detector_spawn_enabled` is on by default and will ban somebody for a spawn-room accident, so read the `_kills`, `_damage` and `_ban_time` values before you open the doors. `enable_whitelist: true` plus `UserIDWhitelist.txt`, with one entry per line in the form `76561198071934271@steam` or `274613382353518592@discord`, is the simplest way to run a private server. One correction to a lot of older guides: `smart_class_picker`, `human_class_ratio` and `scp_ratio` are not part of the current configuration. Class distribution is driven by `team_respawn_queue`, a digit string where each digit is a class slot, plus `server_forced_class`. If you find a config template containing the old keys, it was written for a build several major versions ago and the rest of it is probably stale too. #### Remote Admin: roles, members and permissions `config_remoteadmin.txt` is where you make yourself an admin, and its format is unusual enough to be worth getting exactly right. Three parts: who is in which role, what each role looks like, and which roles hold which permission. config_remoteadmin.txt: ```yaml Members: - 76561198801452050@steam: owner - 2141379914474455080@discord: moderator owner_badge: SERVER OWNER owner_color: red owner_cover: true owner_hidden: false owner_kick_power: 255 owner_required_kick_power: 255 Permissions: - AdminChat: [owner, moderator] - KickingAndShortTermBanning: [owner, moderator] - PlayersManagement: [owner] - ServerConsoleCommands: [owner] ``` The member ID takes a suffix that says which identity provider it is: `@steam` for a 17-digit SteamID64, `@discord` for a Discord snowflake, `@northwood` for a Northwood account. Role options are prefixed with the role name and an underscore - there is no `$` syntax here, whatever an older guide says. Permissions are listed the other way round from how people expect: one line per permission node, naming every role that holds it, with a comma **and** a space between the role names. `kick_power` and `required_kick_power` are the part worth thinking about. A role can only kick or ban somebody whose `required_kick_power` is at or below its own `kick_power`, which is how you stop a junior moderator banning the owner. That is the same least-privilege thinking as [subusers and least privilege](https://www.renode.space/blog/subusers-and-least-privilege) on the panel side, and it deserves as much care. There are twenty-nine permission nodes. The ones you will hand out most: `AdminChat`, `KickingAndShortTermBanning`, `BanningUpToDay`, `LongTermBanning`, `PlayersManagement`, `GameplayData`, `Overwatch`, `Noclip`, `ForceclassSelf`, `GivingItems`, `RoundEvents`, `WarheadEvents`, `Broadcasting`. Three deserve care because they are effectively root: `PermissionsManagement` lets somebody rewrite this file's effect, `ServerConfigs` lets them change the gameplay config, and `ServerConsoleCommands` gives them the server console. After editing, run `reload rolesconfig` rather than restarting, and check the result in game with the `perm` command. #### The commands you will actually use Open Remote Admin in game with `M` by default. The panel is mostly buttons, with a text console at the bottom. The commands worth memorising: | Command | Syntax | | --- | --- | | Admin chat | `@` | | `broadcast` / `bc` | `broadcast ` | | `ban` | `ban ` | | `oban` | `oban ` | | `unban` | `unban id ` or `unban ip
` | | `cassie` | `cassie ` | | `disarm` / `release` | `disarm ` / `release ` | | `hp` | `hp ` | | `setgroup` | `setgroup ` | | `ffd` | `ffd status` / `ffd pause` / `ffd unpause` | | `roundtime` / `rt` | `roundtime` | | `stopnextround` | `stopnextround` | | `config` / `cfg` | `config reload` / `config value