This page contains a comprehensive list of all the Wings-provided variables we found by analyzing the actual eggs in the repository. This shows you exactly what variables are available and how they're used in real eggs!

Quick Summary

Wings provides these main variable categories:

Server Configuration — Port, name, memory
Environment Variables — Custom variables from your egg
Docker Configuration — Information about the container
Build Information — Server build details

The Most Common Wings Variables

`{{server.build.default.port}}`

Purpose: The default port allocated to this server

Used in: Configuration files only (NOT in startup commands!)

How often: Found in ~40+ eggs

Examples:

{
  "caddy.json": {
    "parser": "json",
    "find": {
      "apps.http.servers.srv0.listen.0": ":{{server.build.default.port}}"
    }
  }
}

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

Real eggs using this:

5e-tools (web server)
Code-Server (IDE)
PhantomBot (Twitch bot)
SogeBot (Twitch bot)
MariaDB (database)
PostgreSQL (database)
Elasticsearch
Grafana
Loki
Prometheus
Meilisearch

Why use it:

Wings automatically assigns unique ports
Prevents port conflicts between servers
Users can't accidentally use the same port twice

`{{server.build.env.VARIABLE_NAME}}`

Purpose: Access environment variables you define in your egg

Used in: Configuration files

How often: Found in ~100+ eggs (most common!)

Example:

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

Real eggs using this:

Corpbot (Discord bot) — token, prefix
Fragbot (Discord bot) — token
Ree6 (Discord bot) — extensive use for database and API configs
Redbot (Discord bot) — token, prefix
Code-Server — password
PhantomBot — channel, owner, web panel credentials
And many, many more!

Why use it:

Lets users customize your egg without editing files manually
Keeps secrets secure (passwords, tokens)
No need to hardcode sensitive information

`{{VARIABLE_NAME}}`

Purpose: Direct access to variables in startup commands

Used in: Startup command only (not config files)

How often: Found in ~50+ eggs

Example:

{
  "startup": "java -Xms128M -XX:MaxRAMPercentage=95.0 -jar {{SERVER_JARFILE}}"
}

Real eggs using this:

Counter-Strike 2 — SERVER_PORT, TV_PORT, MAX_PLAYERS, SERVER_NAME, GAME_MODE, GAME_TYPE, and more
Minecraft (various) — SERVER_JARFILE, SERVER_PORT
Rust — port settings
Valheim — memory, port, name
Game server launchers of all kinds

Why use it:

Simpler syntax than {{server.build.env.VAR}}
The correct format for startup commands
Cannot be used in file parsers — use {{server.build.env.VAR}} there instead

`{{config.docker.IMAGE}}`

Purpose: Information about the selected Docker image

Used in: Startup commands (for logging/debugging)

How often: Found in a few eggs

Example:

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

Why use it:

Debugging — know which image was selected at startup
Logging — track which environment is active
Useful when an egg supports multiple Docker images

Complete Variable Reference by Egg Type

Discord Bots

Common variables:

{{server.build.env.BOT_TOKEN}} — Bot authentication token
{{server.build.env.BOT_PREFIX}} — Command prefix (!, /, etc.)
{{server.build.env.BOT_OWNER}} — Owner user ID
{{server.build.env.DATABASE_HOST}} — Database host
{{server.build.env.DATABASE_USER}} — Database user
{{server.build.env.DATABASE_PW}} — Database password
{{server.build.env.DATABASE_PORT}} — Database port
{{server.build.env.SPOTIFY_CLIENT_ID}} — Spotify API credential
{{server.build.env.AI_TOKEN}} — AI/OpenAI API token

Eggs analyzed:

Corpbot — Token, prefix
Fragbot — Token
Ree6 — Extensive: database, API tokens for Spotify/Twitch/Twitter/OpenAI, status
Redbot — Token, prefix
Muse — Token, YouTube key, Spotify credentials
PhantomBot — Channel, owner, web panel credentials

Game Servers

Common variables:

{{SERVER_PORT}} — Game port (in startup)
{{TV_PORT}} — Spectator/SourceTV port (CS2)
{{MAX_PLAYERS}} — Maximum concurrent players
{{SERVER_NAME}} — Server display name
{{GAME_MODE}} / {{GAME_TYPE}} — Game configuration
{{SERVER_PASSWORD}} — Join password
{{RCON_PASSWORD}} — Admin password

Eggs analyzed:

Counter-Strike 2 — Complete example with all variables
Minecraft (various) — SERVER_JARFILE, port via {{server.build.default.port}} in config
Rust — Memory, port
Valheim — Memory, port, name
Garry's Mod — Port, name, password

Web Applications & Services

Common variables:

{{server.build.default.port}} — Application port (in config files)
{{server.build.env.PASSWORD}} — Admin/access password
{{server.build.env.DATABASE_URL}} — Database connection string
{{server.build.env.API_KEY}} — API authentication
{{server.build.env.NODE_ENV}} — Environment (development, production)

Eggs analyzed:

Code-Server — Password, port
Gitea — Configuration
Owncast — Streaming service
Minio — S3 storage
Uptime Kuma — Monitoring

Databases

Common variables:

{{server.build.default.port}} — Database port (in config files)
{{server.build.env.DATABASE_USER}} — Database user
{{server.build.env.DATABASE_PASSWORD}} — Database password
{{server.build.env.DATABASE_NAME}} — Database name

Eggs analyzed:

MariaDB — Port, user, socket
PostgreSQL — Port, user, directory
MongoDB — Authorization settings
Redis — Port, password, memory limits
RethinkDB — Port, HTTP port, cluster port

Variable Naming Patterns

By analyzing all eggs, we found consistent naming conventions:

Server/Network Settings

SERVER_PORT
SERVER_NAME
SERVER_PASSWORD
SERVER_MEMORY
MAX_PLAYERS
TV_PORT     (spectator port)
RCON_PORT   (admin port)

Authentication

BOT_TOKEN
DISCORD_TOKEN
API_TOKEN
API_KEY
PASSWORD
ADMIN_PASSWORD
RCON_PASSWORD

Database Settings

DATABASE_HOST
DATABASE_PORT
DATABASE_USER
DATABASE_PW   (or DATABASE_PASSWORD)
DATABASE_DB   (database name)

Service Configuration

{SERVICE}_TOKEN
{SERVICE}_KEY
{SERVICE}_URL
{SERVICE}_ID
{SERVICE}_SECRET

Examples:

SPOTIFY_CLIENT_ID, SPOTIFY_CLIENT_SECRET
TWITCH_CLIENT_ID, TWITCH_CLIENT_SECRET
TWITTER_CONSUMER_ID, TWITTER_CONSUMER_SECRET
AI_TOKEN, AI_URL, AI_MODEL

Advanced Variables Usage

In Startup Commands

Variables in startup use the simple {{VAR}} format:

{
  "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_JARFILE}}, {{SERVER_NAME}}, etc.
The direct {{VAR}} format — no prefix

Note: {{server.build.default.port}} does NOT work in startup. Port in startup comes from a user-defined variable like {{SERVER_PORT}}.

In Configuration Files

Variables in config files use the full path format:

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

Available variables:

{{server.build.default.port}} — Wings-allocated port (only works here!)
{{server.build.env.VARIABLE}} — Your egg's variables

Real-World Variable Usage Examples

Example 1: Counter-Strike 2 (Complete)

From our analysis, the full real CS2 startup command is:

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}}

Variables used (all {{DIRECT_FORMAT}} because this is a startup command):

{{SERVER_PORT}} — Game port
{{TV_PORT}} — SourceTV spectator port
{{MAX_PLAYERS}} — Player limit
{{GAME_MODE}} — Game mode setting
{{GAME_TYPE}} — Game type setting
{{SRCDS_MAP}} — Starting map
{{SERVER_NAME}} — Server name shown in the browser
{{SERVER_PASSWORD}} — Join password
{{RCON_PASSWORD}} — Admin command access
{{STEAM_GSLT}} — Steam Game Server Login Token
{{VAC_ENABLED}} — Controls VAC anti-cheat (used in shell conditional)
{{RCON_ENABLED}} — Controls RCON (used in shell conditional)

Note the shell conditionals: $( [ "$VAC_ENABLED" == "1" ] || printf %s ' -insecure' ) — this is bash logic that adds the -insecure flag only when VAC is disabled. The $VAC_ENABLED references inside the conditional are shell variable syntax, while {{VAC_ENABLED}} is how you reference them in the egg definition.

Example 2: Ree6 Discord Bot (Complete)

From our analysis, Ree6 uses the YAML parser with a very detailed config:

{
  "config.yml": {
    "parser": "yaml",
    "find": {
      "hikari.sql.user": "{{server.build.env.DATABASE_USER}}",
      "hikari.sql.db": "{{server.build.env.DATABASE_DB}}",
      "hikari.sql.pw": "{{server.build.env.DATABASE_PW}}",
      "hikari.sql.host": "{{server.build.env.DATABASE_HOST}}",
      "hikari.sql.port": "{{server.build.env.DATABASE_PORT}}",
      "hikari.misc.storage": "{{server.build.env.DATABASE_TYP}}",
      "hikari.misc.storageFile": "{{server.build.env.DATABASE_FILE}}",
      "hikari.misc.poolSize": "{{server.build.env.DATABASE_POOL}}",
      "hikari.misc.createEmbeddedServer": "{{server.build.env.DATABASE_EMBEDDED}}",
      "heartbeat.url": "{{server.build.env.HEARTBEAT_URL}}",
      "dagpi.apitoken": "{{server.build.env.DAGPI_TOKEN}}",
      "sentry.dsn": "{{server.build.env.SENTRY_DSN}}",
      "spotify.client.id": "{{server.build.env.SPOTIFY_CLIENT_ID}}",
      "spotify.client.secret": "{{server.build.env.SPOTIFY_CLIENT_SECRET}}",
      "twitch.client.id": "{{server.build.env.TWITCH_CLIENT_ID}}",
      "twitch.client.secret": "{{server.build.env.TWITCH_CLIENT_SECRET}}",
      "twitter.consumer.key": "{{server.build.env.TWITTER_CONSUMER_ID}}",
      "twitter.consumer.secret": "{{server.build.env.TWITTER_CONSUMER_SECRET}}",
      "twitter.access.key": "{{server.build.env.TWITTER_ACCESS_ID}}",
      "twitter.access.secret": "{{server.build.env.TWITTER_ACCESS_SECRET}}",
      "reddit.client.id": "{{server.build.env.REDDIT_CLIENT_ID}}",
      "reddit.client.secret": "{{server.build.env.REDDIT_CLIENT_SECRET}}",
      "bot.tokens.release": "{{server.build.env.BOT_TOKEN}}",
      "openai.apiToken": "{{server.build.env.AI_TOKEN}}",
      "openai.apiUrl": "{{server.build.env.AI_URL}}",
      "openai.model": "{{server.build.env.AI_MODEL}}",
      "bot.misc.status": "{{server.build.env.MISC_STATUS}}",
      "bot.misc.name": "{{server.build.env.MISC_NAME}}",
      "bot.misc.shards": "{{server.build.env.MISC_SHARD}}"
    }
  }
}

Variables grouped by category:

Database (9 variables): DATABASE_USER, DATABASE_DB, DATABASE_PW, DATABASE_HOST, DATABASE_PORT, DATABASE_TYP, DATABASE_FILE, DATABASE_POOL, DATABASE_EMBEDDED
Spotify (2 variables): SPOTIFY_CLIENT_ID, SPOTIFY_CLIENT_SECRET
Twitch (2 variables): TWITCH_CLIENT_ID, TWITCH_CLIENT_SECRET
Twitter (4 variables): TWITTER_CONSUMER_ID, TWITTER_CONSUMER_SECRET, TWITTER_ACCESS_ID, TWITTER_ACCESS_SECRET
Reddit (2 variables): REDDIT_CLIENT_ID, REDDIT_CLIENT_SECRET
OpenAI (3 variables): AI_TOKEN, AI_URL, AI_MODEL
Bot config (4 variables): BOT_TOKEN, MISC_STATUS, MISC_NAME, MISC_SHARD
Monitoring (3 variables): HEARTBEAT_URL, DAGPI_TOKEN, SENTRY_DSN

The dot notation — hikari.sql.host, twitter.consumer.key, etc. — must match the real nested YAML structure in the config.yml file exactly.

Example 3: Code Server (File Parser Example)

{
  ".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 different variable types side by side:

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

Also notice: "parser": "file" is used even though the file extension is .yaml. This is intentional and correct — you pick the parser based on how you want to edit the file, not just its extension.

Example 4: Paper (Minecraft) — Properties Parser

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

The properties parser find values are ONLY the new values — not full key=value lines. Wings writes server-port=25565 for you based on "server-port": "{{server.build.default.port}}".

Variables by File Format

JSON Files

Used with: "parser": "json"
Variables: {{server.build.default.port}}, {{server.build.env.VAR}}
Examples: config.json, settings.json, caddy.json
5e-tools and Corpbot use this

YAML Files

Used with: "parser": "yaml" (or "parser": "file" for line replacement)
Variables: {{server.build.default.port}}, {{server.build.env.VAR}}
Examples: config.yml, settings.yaml
Ree6 bot uses yaml parser extensively

Properties Files

Used with: "parser": "properties"
find value is ONLY the new value (Wings writes key=value for you)
Variables: {{server.build.default.port}}, {{server.build.env.VAR}}
Examples: server.properties, bot.properties
Paper (Minecraft) and PhantomBot use this

INI Files

Used with: "parser": "ini"
Dot notation: section.key
Variables: {{server.build.default.port}}, {{server.build.env.VAR}}
Examples: .my.cnf (MySQL/MariaDB)

Plain Text / Mixed Format Files

Used with: "parser": "file"
find value is the ENTIRE replacement line
Variables: {{server.build.default.port}}, {{server.build.env.VAR}}
Examples: Code-Server's .yaml config, custom text configs
The file parser works on any text file regardless of extension

Statistics from Real Eggs

Here's what we found analyzing all eggs:

Total eggs analyzed: 300+
Using {{server.build.default.port}}: ~40 eggs
Using {{server.build.env.VAR}}: ~100+ eggs (most common!)
Using {{VARIABLE}}: ~50 eggs (in startup)
Using file parsers: ~80 eggs
Most common variable: BOT_TOKEN (in Discord bots)
Most eggs by category: Discord bots (30+), Game servers (50+), Databases (20+)

Important Notes ⚠️

Case Sensitivity: Variable names are CASE-SENSITIVE!
- {{SERVER_PORT}} ≠ {{server_port}}
- {{server.build.env.TOKEN}} ≠ {{server.build.env.token}}
Variable Scope: Different variables work in different places
- Startup: {{VAR}} format
- Config files: {{server.build.env.VAR}} format
- Port: {{server.build.default.port}} in config files ONLY — never in startup!
Properties Parser Rule: When using "parser": "properties", the find value is ONLY the new value, not a full key=value line. Wings writes the full line for you.
File Parser Rule: When using "parser": "file", the find value IS the entire replacement line. You write it completely.
Parser vs Extension: The parser name doesn't have to match the file extension. Code Server uses "parser": "file" for a .yaml file — that's correct!
Always Test: Before sharing your egg, test with different values to make sure everything substitutes correctly.

Troubleshooting

Variable Not Substituting?

Check:

Is the variable name exactly spelled right? (case-sensitive!)
Is it defined in your variables section?
Are you using the right format?
- Startup: {{VAR}}
- Config files: {{server.build.env.VAR}}
- Port in config files: {{server.build.default.port}}

Port Conflicts?

Always use {{server.build.default.port}} in your config files for the main port. Wings handles allocation automatically and guarantees each server gets a unique port.

Wrong YAML Path?

If a YAML variable isn't being substituted, double-check the dot notation path matches the real structure of the file. database.host and hikari.sql.host are completely different paths even if they both refer to a database host!

Summary

Key findings from analyzing 300+ real eggs:

{{server.build.default.port}} — Used in ~40 eggs for automatic port handling (config files only!)
{{server.build.env.VARIABLE}} — Used in ~100+ eggs for all kinds of configuration
{{VARIABLE}} — Used in ~50 eggs for startup commands
Five parsers — json, yaml, properties, ini, file — each with different rules for find keys and values
Consistent patterns — Clear naming conventions across all eggs (DATABASE_HOST, BOT_TOKEN, SERVER_PORT, etc.)

Learning Path 📚

You should read the documentation in this order:

Egg Basics — What are eggs and basic structure
Configuration Variables — How to make your egg customizable
Extending Eggs — Creating and extending eggs
Wings Variables — Special variables from the panel
File Parsers — Managing configuration files
Wings Variables Extracted — This page! Real-world examples

Helpful Links 🔗

Back to README — Overview of all documentation
Egg Basics — Start here if you're new
Configuration Variables — Create customizable settings
Extending Eggs — How to extend and create eggs
Wings Variables — Panel-provided variables explained
File Parsers — Automatic file management

All data on this page was extracted directly from real eggs in the repository! 🎯

Happy egg creating! 🥚

🔍 Wings Variables Extracted from Real Eggs

Quick Summary

The Most Common Wings Variables

{{server.build.default.port}}

{{server.build.env.VARIABLE_NAME}}

{{VARIABLE_NAME}}

{{config.docker.IMAGE}}

Complete Variable Reference by Egg Type

Discord Bots

Game Servers

Web Applications & Services

Databases

Variable Naming Patterns

Server/Network Settings

Authentication

Database Settings

Service Configuration

Examples:

Advanced Variables Usage

In Startup Commands

In Configuration Files

Real-World Variable Usage Examples

Example 1: Counter-Strike 2 (Complete)

Example 2: Ree6 Discord Bot (Complete)

Example 3: Code Server (File Parser Example)

Example 4: Paper (Minecraft) — Properties Parser

Variables by File Format

JSON Files

YAML Files

Properties Files

INI Files

Plain Text / Mixed Format Files

Statistics from Real Eggs

Important Notes ⚠️

Troubleshooting

Variable Not Substituting?

Port Conflicts?

Wrong YAML Path?

Summary

See Also 📚

Learning Path 📚

Helpful Links 🔗

`{{server.build.default.port}}`

`{{server.build.env.VARIABLE_NAME}}`

`{{VARIABLE_NAME}}`

`{{config.docker.IMAGE}}`