Startup and Configuration

Introduction

These settings tell Wings how to start a server, detect that it has started, stop it, and keep its configuration files up to date. They are in the Configuration and Process Management cards on the egg's Configuration tab.

Startup Command

The Startup Command runs every time the server starts. Use {{VARIABLE}} to insert one of the egg's variables:

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

The Panel shows users the command with the values filled in.

This is the default for new servers. Each server keeps its own copy, so changing it here does not affect existing servers. To change a server's command, use its Startup tab in the admin area.

The official images run the startup command directly, not through a shell, so &&, |, and > do not work. If you need them, start the command with bash -c, or put the commands in a script the install script creates.

Stop Command

Wings sends the Stop Command to stop the server gracefully. It is either:

a command typed into the server's console, such as stop for Minecraft, or
^C, which sends the process an interrupt signal (SIGINT), like pressing Ctrl+C in a terminal.

If the server does not stop in time, users can kill it from the Panel.

Start Configuration

The Start Configuration tells Wings when the server has started. The Panel shows Starting until one of the done strings appears in the console, then Running:

{
    "done": "Server started on port"
}

done can be a list if the server prints different messages in different situations:

{
    "done": [
        "Done (",
        "Server is ready"
    ]
}

If no string ever appears, the server stays Starting, so match the server's real output.

Log Configuration

Leave Log Configuration as {}. Wings shows the server's console output without it.

Configuration Files

Configuration Files lets Wings set values in the server's configuration files every time it starts. For example, it can keep a game server on its assigned port, whatever a user writes in the file.

The value is a JSON object. Each key is a file path relative to the server's directory, with the parser to use and the settings to set:

{
    "server.properties": {
        "parser": "properties",
        "find": {
            "server-ip": "0.0.0.0",
            "server-port": "{{server.build.default.port}}",
            "max-players": "{{env.MAX_PLAYERS}}"
        }
    }
}

On start, Wings sets each key to its value. Most parsers add missing keys and create the file if it does not exist. The file parser skips a missing file, and the json parser fails on the empty file Wings creates, so have the install script create those files.

Values

A value can be plain text or include these placeholders:

Placeholder	Value
`{{server.build.default.ip}}`	The IP address of the server's primary allocation.
`{{server.build.default.port}}`	The port of the server's primary allocation.
`{{server.build.memory}}`	The server's memory limit, in MiB.
`{{env.VARIABLE}}`	An egg variable's value, such as `{{env.MAX_PLAYERS}}`. For port, IP address, and memory, use the `server` placeholders above; `{{env.SERVER_PORT}}` and similar end up in the file as placeholder text.
`{{config.docker.interface}}`	The node's address on the servers' Docker network, usually `172.18.0.1`.

Parsers

Parser	For
`properties`	`.properties` files, with `key=value` lines.
`ini`	INI files. Keys are `section.key`, such as `Server.Port`. Bracket section names that contain dots, such as `[/Script/Engine.GameSession].MaxPlayers`.
`yaml`	YAML files. Use dots for nested keys, such as `settings.port`, and brackets for list items, such as `listeners[0].host`.
`json`	JSON files. Keys work as for `yaml`.
`xml`	XML files. Keys are element paths, such as `Config.Port` for `<Config><Port>`. Wings sets the element's text, or an attribute if the value is written as `[name='value']`.
`file`	Any text file. Replaces every line starting with the key with the value, so the value must be the whole line, such as `"port=": "port={{server.build.default.port}}"`. It does not add missing lines. Use it only when no other parser fits.

In yaml and json keys, * matches every item at one level. For example, servers.*.port sets the port of every entry under servers. Only the first * in a key works.

Configuration file playground

Try:

The egg's configuration files

"server.properties": { "parser": "properties", "find":

}

The server

Allocation IP

Allocation port

Memory (MiB)

Docker interface

Variables, one NAME=value per line

{{env.*}} also sees STARTUP, P_SERVER_UUID, and P_SERVER_LOCATION.

The file before the server starts

The file exists

1. What the Panel sends Wings

server-ip"0.0.0.0"
server-port"25565"
- {{server.build.default.port}}: Filled in with 25565.
query.port"25565"
- {{server.build.default.port}}: Filled in with 25565.
max-players"50"
- {{env.MAX_PLAYERS}}: Filled in with 50.

2. The file after Wings updates it

updated

setserver-ip(empty) → 0.0.0.0
sameserver-portAlready 25565.
samequery.portAlready 25565.
setmax-players20 → 50

1#Minecraft server properties

2#Mon Oct 06 12:00:00 UTC 2026

3enable-query=false

4server-ip=0.0.0.0

5server-port=25565

6query.port=25565

7motd=A Minecraft Server

8max-players=50

2 lines new or changed, 1 line from the original gone.

Wings keeps the comment lines at the top of the file and drops every comment after the first setting.

Copy Settings From

Copy Settings From makes an egg inherit another egg's Process Management settings. These fields, if left empty, come from the chosen egg: the stop command, the start, log, and configuration file settings, and the features.

This avoids repeating settings across similar eggs, such as several Minecraft server types. Copying goes one level only: settings the chosen egg copies from another egg are not passed on.

Only these settings are copied. The copying egg still needs its own startup command, Docker images, and variables.

On this page