This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

🌐 Wings-Provided Variables Reference

This page lists all the variables that Wings (the panel system) provides automatically. These are different from the variables you create in your egg — Wings gives you these for free! 🎁

Quick Overview

Wings provides variables you can use in your egg files. The most important thing to understand upfront is that different variables work in different places:

{{server.build.default.port}} — The port allocated to this server (config files only!)
{{server.build.env.VARIABLE_NAME}} — Environment variables from your egg (config files)
{{VARIABLE_NAME}} — Variables in startup commands (startup only)
{{config.docker.IMAGE}} — Docker configuration

Understanding Variable Scopes

Think of variable scope like this: where can you use a variable?

This is probably the most important concept on this whole page. Using the wrong variable format in the wrong place means your variable won't be substituted — it'll just appear literally as {{VARIABLE_NAME}} in your config file!

Scope 1: In Startup Command 🚀

In the "startup" field, you use plain variable names wrapped in double curly braces:

{
  "startup": "java -Xms128M -XX:MaxRAMPercentage=95.0 -Dterminal.jline=false -Dterminal.ansi=true -jar {{SERVER_JARFILE}}"
}

Available variables:

Any variable defined in your variables section: {{SERVER_PORT}}, {{SERVER_NAME}}, {{SERVER_JARFILE}}, etc.
Just the variable name — no prefix needed!

⚠️ Important: {{server.build.default.port}} does NOT work in the startup command! That one is for config files only. In startup, the port comes from a user-defined variable like {{SERVER_PORT}}.

Scope 2: In Configuration Files 📝

In the "config.files" section, you use the full path format:

{
  "config.json": {
    "parser": "json",
    "find": {
      "port": "{{server.build.default.port}}",
      "token": "{{server.build.env.BOT_TOKEN}}"
    }
  }
}

Available variables:

{{server.build.default.port}} — Wings-assigned port (only works here, not in startup!)
{{server.build.env.VARIABLE_NAME}} — any egg variable
{{config.docker.IMAGE}} — Docker image info

The Main Wings Variables

1. Server Port 🔌

Variable: {{server.build.default.port}}

The port number that Wings automatically assigns to this server. Wings makes sure every server gets a unique port so they don't crash into each other.

Where to use:

✅ In config.files — to tell your app which port to listen on
❌ NOT in the startup command — the startup command uses a user-defined variable like {{SERVER_PORT}} instead

Example in config files (Paper/Minecraft server.properties):

{
  "server.properties": {
    "parser": "properties",
    "find": {
      "server-ip": "0.0.0.0",
      "server-port": "{{server.build.default.port}}",
      "query.port": "{{server.build.default.port}}"
    }
  }
}

Wings finds the server-port property and replaces its value with the assigned port. Notice the find value is just the port number — you don't write server-port=25565. The properties parser handles putting it all together for you! (See File Parsers Guide for details.)

2. Environment Variables 🔐

Variable: {{server.build.env.VARIABLE_NAME}}

Access any environment variable you defined in your egg's variables section, from within your config.files.

How it works:

You define a variable in your egg:

{
  "variables": [
    {
      "name": "Bot Token",
      "env_variable": "BOT_TOKEN",
      "default_value": ""
    }
  ]
}

The user enters a value in the panel
In config files, you access it with {{server.build.env.BOT_TOKEN}}

Example in config files:

{
  "config.json": {
    "parser": "json",
    "find": {
      "token": "{{server.build.env.BOT_TOKEN}}",
      "prefix": "{{server.build.env.BOT_PREFIX}}"
    }
  }
}

In startup, the same variable is accessed differently (shorter format!):

{
  "startup": "python bot.py --token {{BOT_TOKEN}}"
}

In startup commands, you just use {{BOT_TOKEN}} — no server.build.env. prefix.

3. Direct Variables 📌

Variable: {{VARIABLE_NAME}}

This is how you use variables in your startup command — simple and clean! Think of it like a nickname: in startup you use the short version.

Example:

{
  "variables": [
    {
      "name": "Server Memory",
      "env_variable": "SERVER_MEMORY",
      "default_value": "2048"
    }
  ],
  "startup": "java -Xmx{{SERVER_MEMORY}}M -jar server.jar"
}

This is simpler than {{server.build.env.SERVER_MEMORY}} and it's the correct syntax for startup commands.

4. Docker Configuration 🐳

Variable: {{config.docker.IMAGE}}

Access information about the Docker image being used for this server.

Common uses:

{
  "startup": "echo Running with image {{config.docker.IMAGE}}"
}

This is mostly useful for debugging — it tells you which Docker image was selected when the server starts.

Complete Wings Variable List

Here's a comprehensive list of all Wings variables you can use:

Server Information

Variable	Purpose	Where to Use	Example
`{{server.build.default.port}}`	Default allocated port	Config files only	`"server-port": "{{server.build.default.port}}"`
`{{SERVER_NAME}}`	Server display name	Startup	`+hostname "{{SERVER_NAME}}"`
`{{SERVER_MEMORY}}`	Memory allocation in MB	Startup	`-Xmx{{SERVER_MEMORY}}M`

Environment Access

Variable	Purpose	Where to Use	Example
`{{server.build.env.VAR}}`	Access egg variable	Config files	`"token": "{{server.build.env.BOT_TOKEN}}"`
`{{VAR}}`	Direct variable access	Startup command	`./app --port {{SERVER_PORT}}`

Docker Configuration

Variable	Purpose	Where to Use	Example
`{{config.docker.IMAGE}}`	Selected Docker image	Startup (debugging)	`echo {{config.docker.IMAGE}}`

Real-World Examples from Actual Eggs

Example 1: Discord Bot (Corpbot)

{
  "variables": [
    {
      "env_variable": "TOKEN",
      "default_value": ""
    },
    {
      "env_variable": "PREFIX",
      "default_value": "!"
    }
  ],
  "config": {
    "files": {
      "config.json": {
        "parser": "json",
        "find": {
          "token": "{{server.build.env.TOKEN}}",
          "prefix": "{{server.build.env.PREFIX}}"
        }
      }
    }
  }
}

In the config file, {{server.build.env.TOKEN}} pulls in whatever value the user typed into the panel. Neat!

Example 2: Code Server

{
  "config": {
    "files": {
      ".config/code-server/config.yaml": {
        "parser": "file",
        "find": {
          "password": "password: {{server.build.env.PASSWORD}}",
          "bind-addr": "bind-addr: 0.0.0.0:{{server.build.default.port}}"
        }
      }
    }
  }
}

Two things to notice here:

{{server.build.env.PASSWORD}} — a user-defined variable, used correctly in config files ✅
{{server.build.default.port}} — Wings-provided port, used correctly in config files ✅

And yes — "parser": "file" is correct here even though the file extension is .yaml! The parser name doesn't have to match the file extension. See File Parsers Guide for why.

Example 3: Counter-Strike 2

The full real CS2 startup command:

LD_LIBRARY_PATH="$HOME/game/bin/linuxsteamrt64:$LD_LIBRARY_PATH" ./game/bin/linuxsteamrt64/cs2 -dedicated $( [ "$VAC_ENABLED" == "1" ] || printf %s ' -insecure' ) -ip 0.0.0.0 -port {{SERVER_PORT}} -tv_port {{TV_PORT}} -maxplayers {{MAX_PLAYERS}} $( [ "$RCON_ENABLED" == "0" ] || printf %s ' -usercon' ) +game_mode {{GAME_MODE}} +game_type {{GAME_TYPE}} +map {{SRCDS_MAP}} +hostname "{{SERVER_NAME}}" +sv_password "{{SERVER_PASSWORD}}" +rcon_password "{{RCON_PASSWORD}}" +sv_setsteamaccount {{STEAM_GSLT}}

Every {{VARIABLE}} reference here is a user-defined variable used directly in startup. CS2 uses a lot of them: SERVER_PORT, TV_PORT, MAX_PLAYERS, GAME_MODE, GAME_TYPE, SRCDS_MAP, SERVER_NAME, SERVER_PASSWORD, RCON_PASSWORD, STEAM_GSLT, plus VAC_ENABLED and RCON_ENABLED (used in the shell conditionals).

Notice: there is no {{server.build.default.port}} in the startup command! The port comes from the user-defined SERVER_PORT variable.

Example 4: Minecraft Paper Server

{
  "startup": "java -Xms128M -XX:MaxRAMPercentage=95.0 -Dterminal.jline=false -Dterminal.ansi=true -jar {{SERVER_JARFILE}}",
  "config": {
    "files": {
      "server.properties": {
        "parser": "properties",
        "find": {
          "server-ip": "0.0.0.0",
          "server-port": "{{server.build.default.port}}",
          "query.port": "{{server.build.default.port}}"
        }
      }
    }
  },
  "variables": [
    {
      "env_variable": "SERVER_JARFILE",
      "default_value": "server.jar"
    }
  ]
}

This shows the two different contexts perfectly:

Startup: {{SERVER_JARFILE}} — the direct {{VAR}} format ✅
Config files: {{server.build.default.port}} — Wings-assigned port ✅

The startup command never references {{server.build.default.port}}. The port is handled entirely in the config file.

Variable Naming Conventions

When creating variables, follow these naming rules:

Good Variable Names ✅

{
  "env_variable": "DISCORD_TOKEN",
  "description": "Your Discord bot token — find this in the Discord Developer Portal"
}

✅ All uppercase — Easy to spot in startup commands and config files ✅ Descriptive names — Users immediately understand what they're for ✅ Snake_case — Use underscores between words ✅ Consistent — Related variables share a prefix (like DATABASE_HOST, DATABASE_PORT, DATABASE_USER)

Bad Variable Names ❌

{
  "env_variable": "token"
}

❌ Lowercase — Hard to see in code ❌ Ambiguous — Which token? Discord? Spotify? RCON? ❌ No description — Users have no idea what to enter!

Common Variable Patterns

Pattern 1: Server Configuration

{
  "variables": [
    {
      "env_variable": "SERVER_NAME",
      "default_value": "My Server"
    },
    {
      "env_variable": "SERVER_PORT",
      "default_value": "25565"
    },
    {
      "env_variable": "MAX_PLAYERS",
      "default_value": "20"
    }
  ]
}

Pattern 2: Authentication

{
  "variables": [
    {
      "env_variable": "BOT_TOKEN",
      "default_value": ""
    },
    {
      "env_variable": "API_KEY",
      "default_value": ""
    },
    {
      "env_variable": "ADMIN_PASSWORD",
      "default_value": ""
    }
  ]
}

Pattern 3: Database Connection

{
  "variables": [
    {
      "env_variable": "DATABASE_HOST",
      "default_value": "localhost"
    },
    {
      "env_variable": "DATABASE_PORT",
      "default_value": "5432"
    },
    {
      "env_variable": "DATABASE_USER",
      "default_value": "admin"
    },
    {
      "env_variable": "DATABASE_PASSWORD",
      "default_value": ""
    },
    {
      "env_variable": "DATABASE_NAME",
      "default_value": "myapp"
    }
  ]
}

Accessing Variables in Your Code

In Bash Scripts (Installation)

#!/bin/bash
# In installation scripts, variables are plain environment variables
echo "Server port: $SERVER_PORT"
echo "Bot token: $DISCORD_TOKEN"

# Use them to download the right version
curl -O "https://example.com/releases/server-${VERSION}.jar"

In Startup Command

{
  "startup": "java -Xmx{{SERVER_MEMORY}}M -Xms512M -jar {{SERVER_JARFILE}} --port {{SERVER_PORT}}"
}

In Configuration Files

{
  "config": {
    "files": {
      "config.json": {
        "parser": "json",
        "find": {
          "token": "{{server.build.env.BOT_TOKEN}}",
          "port": "{{server.build.default.port}}"
        }
      }
    }
  }
}

Tips and Tricks 💡

Tip 1: Use Default Values

Always provide sensible defaults so the server works out of the box:

{
  "env_variable": "SERVER_PORT",
  "default_value": "25565"
}

Tip 2: Add Validation

Prevent users from entering invalid values:

{
  "env_variable": "MAX_PLAYERS",
  "rules": "required|numeric|between:1,100"
}

Tip 3: Write Clear Descriptions

{
  "name": "Maximum Players",
  "description": "How many players can join at once (1–100). More players = more CPU and RAM usage!",
  "env_variable": "MAX_PLAYERS"
}

{
  "env_variable": "DATABASE_HOST"
},
{
  "env_variable": "DATABASE_PORT"
},
{
  "env_variable": "DATABASE_USER"
}

All start with DATABASE_ so users can immediately tell they're related!

Troubleshooting Common Issues ❌

Issue: Variable Not Substituting

Problem: Your variable shows literally as {{SERVER_PORT}} instead of the actual value

Solutions:

Check the variable name is spelled correctly — they're case-sensitive!
Check the variable is defined in your variables section
In config.files, use {{server.build.env.VAR}} format
In startup, use {{VAR}} format

Issue: Port Already in Use

Problem: Server won't start because the port is taken

Solution: In your config files, use {{server.build.default.port}} — Wings assigns unique ports automatically, so each server gets its own!

Issue: Variable Empty

Problem: Variable appears as an empty string