Aloft Dedicated Server Setup Guide 2026

An Aloft dedicated server removes that dependency by running the world as a separate headless process for up to eight players. On Windows, you create and load the world using the bundled AloftServerNoGuiCreate.ps1 and AloftServerNoGuiLoad.ps1 scripts.

Players can join through the multiplayer browser or a room code, while launch settings control visibility, player limits, admins, and home-island protection. The server machine, server process, and required Steam session must remain active while players connect.

This guide takes you from the initial server files to a working multiplayer world, then explains room codes, networking, saves, backups, and common connection problems.

It also covers the practical limits of hosting Aloft through Wine, SteamCMD, Docker, or rented infrastructure.

Aloft Dedicated Server: Quick Facts

Aloft uses main Steam App ID 1660080, and its bundled Windows scripts are the documented server method. A separate public dedicated-server Tool app was not verified, so depot listings should not be treated as proof of a separate application.

Current Release and Compatibility

Aloft remains in Early Access, and Discovery & Ancestry has shipped. As of September 17, 2026, the latest listed patch is version 0.3.6.50, published September 11, 2026.

After updates, test existing worlds and confirm that the server loads the intended save before migrating or creating a new world. The dedicated-server workflow still uses the bundled Windows scripts.

Aloft Dedicated Server System Requirements

CPU Requirements

The figures below are historical or illustrative planning notes, not tested Aloft dedicated-server requirements.

Community CPU starting point:

• Quad-core processor
• No current official core-count requirement was verified for the dedicated server.

A modern desktop CPU or entry-level server processor is a reasonable starting point for small 2–8 player groups, but actual requirements may vary by build and workload.

Memory Requirements

Older community reports suggest modest memory usage for small groups.

Community Memory Estimate:

• Historical planning example; measure peak memory before assigning a capacity

Memory demand may rise when players explore, load, or save larger world areas.

Storage Requirements

Measure the installed directory for the selected build. Reserve measured installation space plus separate headroom for saves, backups, and update staging, and label units as GB or GiB.

Practical Storage Allowance:

• Measured installation size plus separate space for saves, backups, and update staging

SSD storage is a sensible choice for server files and saves, although actual loading and saving performance depends on the workload.

Network Bandwidth

Aloft does not have a verified dedicated-server bandwidth requirement. Once upload capacity is sufficient, prioritize stable latency and low packet loss.

Verify sufficient upload capacity, then check latency and packet loss for the workload you actually run.

Example Hardware Scenarios

The following configurations are practical planning examples based on older community guidance, not official Aloft dedicated-server requirements.

Small Private World (2–4 players)

• Quad-core CPU
• 2–4 GB RAM
• SSD storage
• Stable home internet connection

Mid-Size Multiplayer Group (6–8 players)

• Quad-core CPU
• 4 GB RAM
• SSD storage
• Reliable broadband connection

Persistent Community Server

• Quad-core CPU with strong single-thread performance
• 4+ GB RAM
• SSD or NVMe storage
• Stable high-bandwidth connection

Operating System Compatibility

Aloft’s public Steam listing confirms Windows support. Windows 10 and Windows 11 are the safest documented environments. Windows Server editions may also work, but specific versions are not officially verified for Aloft dedicated servers.

The server runs through PowerShell scripts included in the game files.

Key scripts include:

• AloftServerNoGuiCreate.ps1
• AloftServerNoGuiLoad.ps1

These scripts create the world and launch the headless server.

Why Infrastructure Stability Matters

Multiplayer survival games run continuous world simulations. If the host system becomes unstable, players experience disconnects or delayed world updates.

Running the server on stable hardware or dedicated infrastructure helps maintain consistent uptime for persistent multiplayer worlds.

How to Set Up an Aloft Dedicated Server (Step-by-Step Guide)

Before you begin: use a Windows machine with Steam installed, an Aloft-owning Steam account, the current game files, and permission to edit and run the bundled PowerShell scripts. The hosting machine and required Steam session must remain running while players connect.

Let’s walk through how to create and run an Aloft dedicated server. Aloft does not appear to ship as a separate public Steam dedicated-server Tool app. Instead, the server mode launches from the main game files through PowerShell scripts.

You will use two scripts:

• AloftServerNoGuiCreate.ps1 - Creates the world
• AloftServerNoGuiLoad.ps1 - Launches the server

Step 1: Locate the Aloft Server Files

First, locate the server scripts inside the game directory.

Open Steam and go to your Library.

Right-click Aloft, then select:

Properties → Installed Files → Browse

Steam will open the game installation folder.

Inside this directory you will find two important scripts:

• AloftServerNoGuiCreate.ps1
• AloftServerNoGuiLoad.ps1

Instead of installing a separate server package, Aloft launches a headless server instance from the game files.

Step 2: Create a New Aloft Server World

Next, generate the world your server will run.

Open the file:

AloftServerNoGuiCreate.ps1

Find the line that contains:

$processInfo.Arguments

This line controls world creation.

Example Configuration:

-batchmode -nographics -server create#MAPNAME# islandcount#normal# corruptioncount#normal# creative#false# log#ERROR#

Parameter Explanation

World Name

→ create#MyWorld#

Sets the world name. Avoid spaces.

Island Count

The create script now uses the islandcount parameter. Accepted values are 0, 1, 2 or the named presets normal, big, and huge.

Example:

-server create#MyWorld# islandcount#normal# corruptioncount#normal# creative#false# log#ERROR#

Corruption Count

Use the corruptioncount parameter to control the number of corrupted islands.

Accepted Named Values:

• none
• little
• normal
• lots
• shrooms

Numeric values from 0 through 4 are also accepted.

Game Mode

Use the creative parameter:

• creative#false# = Survival
• creative#true# = Creative

The numeric values 0 and 1 are also accepted.

Optional Headless Flag

disablevideo#true#

Some provider guides include this flag for headless deployments. Use it only when the script or documentation for your deployment includes it.

Without this parameter, the console may display:

Video shaders not found

After editing the parameters, run the script.

Right-click the file and select:

Run with PowerShell

The script generates the world and then closes automatically.

You only run this step once per new world.

Step 3: Launch the Aloft Dedicated Server

Now start the server using the second script.

Open:

AloftServerNoGuiLoad.ps1

Locate the same line that defines the server arguments inside the script.Depending on the script version, this appears as either:

$psi.Arguments

or

$processInfo.Arguments

Edit the value assigned to this variable to change server settings.

Keep the variable name already present in the script.

For example, if the file uses $processInfo.Arguments: $processInfo.Arguments = "-batchmode -nographics -server load#MyWorld# servername#SkyIslandServer# log#ERROR# isvisible#false# privateislands#true# playercount#8# serverport#<ASSIGNED_PORT># admin#YOUR_STEAMID64#"

Save the script before running it, and replace every placeholder with values valid for your deployment.

Server Name

servername#SkyIslandServer#

Name shown in the multiplayer browser.

Server Visibility

isvisible#true#

• True → Allows the server to appear in the public list, subject to startup, region, version, and deployment checks
• False → Hidden from the browser; players still join with the room code

Player Limit

playercount#8#

Aloft currently supports up to 8 players per server.

Private Islands

privateislands#true#

Affects home-island spawning protection; verify the exact permission behavior in your build.

Use only after confirming the setting’s in-game behavior; it does not guarantee that players cannot interfere with home islands.

Server Port

serverport#0#

For a fixed port, use the value assigned by your provider or documented for this deployment:

serverport#<ASSIGNED_PORT>#

Older community guides mention 15636/15637, but those values are historical examples and are not universal Aloft defaults.

Admin Steam IDs

admin#STEAMID#

Grants administrator permissions to specific players.

Add another admin#STEAMID64# token inside the same quoted launch-argument string.

After configuring the script:

Right-click AloftServerNoGuiLoad.ps1 and select Run with PowerShell.

The server will start and begin loading the world.

Step 4: Join the Server From the Game Client

Once the server launches, players can connect from the game. Open Aloft and select Multiplayer.

Players can connect in two main ways.

Server Browser

If the server is public, search for the server name in the multiplayer list.

Room Code Join

If the server does not appear in the list, use the room code.

When the server launches, it generates a room code that players use to connect.

You can find the code in two places:

• The console output when the server starts
• The file ServerRoomCode.txt created in the server directory

Region Filtering

If the server still does not appear, check the region filter in the multiplayer menu.

Some servers only appear under specific regions.

Aloft Server Settings Explained

The load script controls how your multiplayer server behaves. These parameters define server visibility, player limits, networking, and administration.

Below are the most important Aloft server settings used in AloftServerNoGuiLoad.ps1.

Core Server Configuration

playercount currently supports up to 8 players.

Do not assume how serverport#0# behaves unless the script or provider documentation for your deployment explains it.

This option controls protection for home-island spawning on public servers.

Its exact behavior may depend on the current game build and server configuration.

Administration Settings

Admins can manage players and monitor the server.

You can add multiple admins.

Example:

admin#STEAMID64_1#admin#STEAMID64_2#

Important Note About Creative Mode

The creative mode setting is not part of the load script.

It is defined during world creation in:

AloftServerNoGuiCreate.ps1

Aloft Dedicated Server Password and Admin Access

Aloft does not provide a documented traditional server-password parameter; hidden visibility and room-code access are separate controls.

Instead, server access usually relies on two mechanisms:

• Server visibility
• Room code joining

Public vs Private Servers

The isvisible parameter controls server discovery.

Hidden servers require players to join using the room code.

Room Code Access

When the server starts it generates:

ServerRoomCode.txt

This file contains the join code.

Players can enter this code inside the multiplayer menu to connect.

Important Limitation

Provider guides report that the room or friend code may change after restarts or settings changes. Check ServerRoomCode.txt before sharing the current code.

A changing room code does not establish whether a separate password system exists; Aloft’s password status is a separate documented limitation.

Admin Access

Admins are assigned using Steam IDs.

Example:

admin#76561197960287930#

Admins can help manage multiplayer sessions and maintain server stability.

For community servers it is recommended to assign at least one trusted administrator besides the host.

Best Practices for Private Servers

To run a controlled multiplayer environment:

• Set isvisible#false#
• Share the room code with trusted players
• Assign one or more admins
• Enable privateislands#true#

These settings control listing and home-island behavior; protect saved progress separately with tested backups and restores.

Aloft Dedicated Server List and Server Discovery

Let’s discuss how servers appear in the Aloft dedicated server list and how players connect.

After startup completes, confirm that the server process remains running and produces the room-code file. Public visibility can make a server eligible for browser listing, but appearance depends on startup, region, version, and deployment conditions.

Server visibility depends on the following setting:

isvisible#true#

Hidden servers require players to join using a room code.

Room Code Joining

When the server launches it generates a file:

ServerRoomCode.txt

This file contains the code players enter in the multiplayer menu.

Example workflow:

1. The host starts the server
2. Server generates ServerRoomCode.txt
3. The host shares the code with players
4. Players enter the code in the join menu

Important Limitation: No Documented Direct IP or DNS Join

Many server admins expect to share a hostname or IP address.

Use the in-game browser or room/friend code for the documented workflow. Current public setup documentation does not establish a universal direct-IP joining method.

Players commonly connect using:

• The in-game server browser
• The room code

Check discovery separately from connectivity: verify startup and version, read the current room code, confirm visibility and region, then follow the network instructions for your deployment.

Why Servers May Not Appear

If your server does not appear in the Aloft dedicated server list, check these first:

• Server startup and game version
• Deployment-specific networking settings
• isvisible configuration
• Region filter in the client

Use these diagnostic categories rather than assuming a single cause: startup and version, room code, visibility and region, then deployment-specific networking.

Aloft Dedicated Server on Linux: Unofficial Wine/SteamCMD Approach

Many administrators search for aloft dedicated server linux, but the situation requires explanation.

Aloft’s public Steam listing shows Windows support, and a native Linux dedicated-server build was not publicly verified. The bundled Windows workflow uses PowerShell scripts; a Wine route is unofficial and must be tested for the chosen build.

However, some experienced administrators attempt to run the server on Linux using compatibility layers such as Wine.

Common Linux Hosting Approach

A common unofficial setup uses:

• SteamCMD
• Wine
• Authenticated Steam account

Typical Workflow:

1. Install Wine
2. Install SteamCMD
3. Install Aloft game files through SteamCMD

Run the Aloft game executable or server mode through Wine using launch parameters derived from the PowerShell scripts

Example installation commands:

sudo apt update

sudo apt install wine steamcmd # Ubuntu example; verify repositories and package availability first

Login to SteamCMD:

steamcmd

Set the installation directory:

force_install_dir /home/steam/aloft

Force SteamCMD to request the Windows depot:

@sSteamCmdForcePlatformType windows

Authenticate with your Steam account:

login your_steam_username

Install Aloft:

app_update 1660080 validate

Running the Server via Wine

Once installed, administrators typically launch the Aloft executable or server mode through Wine using the arguments found in the PowerShell scripts.

Important detail:

The PowerShell scripts act as a reference for the correct launch parameters.

Linux administrators often translate those arguments into their own startup commands.

Limitations of Linux Hosting

Linux hosting may work through Wine, but it introduces extra complexity.

Common challenges include:

• Steam authentication requirements
• Wine compatibility issues
• Container networking configuration
• Troubleshooting Unity headless mode

Windows follows the documented bundled PowerShell workflow, while Wine-based Linux hosting remains an unofficial approach that requires additional testing.

Aloft Dedicated Server With SteamCMD: Use App ID 1660080 With an Authenticated Account

SteamCMD is widely used to deploy game servers, but Aloft behaves differently. Public SteamDB depot records for Aloft show the Windows game depot and DLC depots, not a separate public dedicated-server depot.

Instead, the server files come from the full game installation. This means administrators should use an authenticated Steam account that owns the game unless another verified install method is confirmed.

When running SteamCMD on Linux, set an installation directory and enter @sSteamCmdForcePlatformType windows before app_update so SteamCMD requests Aloft’s Windows depot.

Typical installation process:

steamcmd
force_install_dir /home/steam/aloft
@sSteamCmdForcePlatformType windows
login your_steam_username
app_update 1660080 validate
quit

After installation, administrators launch the server using the same arguments defined in the PowerShell scripts.

This approach is useful for advanced administrators who want repeatable deployments.

Aloft Dedicated Server Docker and Container Hosting

Some operators explore Aloft hosting in Docker with a Wine-based Windows runtime. A Docker image packages the runtime and dependencies; a container runs that image.

This can simplify deployments across multiple machines.

Example Docker-Based Launch Concept

A typical container workflow includes:

• Wine runtime
• SteamCMD installation
• Aloft server files
• automated startup script

Using disablevideo#true# When Documented

Unity servers running in headless mode can trigger shader errors.

This parameter can help reduce shader-related errors or warnings during headless operation.

Example:

disablevideo#true#

Use disablevideo#true# in no-GUI or headless deployments if your script or guide includes it, especially when troubleshooting shader warnings.

Practical Recommendation

For most server operators:

• Windows servers provide the simplest setup
• Linux hosting may work through Wine but requires additional configuration
• Docker deployments are best suited for advanced administrators because they still need Wine, Steam authentication, file persistence, and container networking

Choose the deployment method that matches your experience level and infrastructure.

Save Files, Backups, and World Persistence

Let’s explore where an Aloft dedicated server stores its data and how to protect it.

Current Save Location: Verify the Active Data Folder

Use the active data folder on the machine running the server.

Current Aloft hosting and save-upload guides document Windows paths such as:

C:\Users\<username>\AppData\LocalLow\Astrolabe Interactive\Aloft\Data01\Saves

or, on newer builds and references:

%appdata%\..\LocalLow\Astrolabe Interactive\Aloft\data06\Saves

Back up the active Aloft data folder, including Saves and any configuration or player data needed for your recovery plan; verify the contents of any recursive parent-folder copy.

What the Server Actually Saves

Current guides document world saves inside the active data directory. Back up the world save used by the running server, then preserve any separate character, personal-home, and configuration data required for account recovery.

Manual Backup

Stop the server first, then use Command Prompt to copy the active save folder to a new timestamped backup location.

Example:

robocopy "C:\Users<username>\AppData\LocalLow\Astrolabe Interactive\Aloft\Data01\Saves" "D:\AloftBackups<timestamp>\Saves" /E

If your server build uses data06, use that path instead:

robocopy "%appdata%..\LocalLow\Astrolabe Interactive\Aloft\data06\Saves" "D:\AloftBackups<timestamp>\Saves" /E

This copy is a precaution; keep multiple timestamped snapshots and test a restore before relying on them. Save-upload documentation helps identify the active Saves path, but copying, retention, and restore behavior still require your own validation.

Manual Restore

To restore a world into a clean target and verify it:

1. Stop the server
2. Preserve the current target, then restore the selected snapshot into a clean active Saves directory
3. Start the server, join the restored world, and confirm the expected state survives a later restart

Example:

robocopy "D:\AloftBackups<timestamp>\Saves" "C:\Users<username>\AppData\LocalLow\Astrolabe Interactive\Aloft\Data01\Saves" /E

If the server uses data06, restore into that active folder instead.

Why Backups Matter Before Updates

Backups are strongly recommended before updates, migrations, experiments, or manual save edits. They are a practical safeguard against broken updates, test changes, and save migrations.

Current custom world upload guides rely on direct file handling inside the save directory, which makes regular offline copies one of the safest habits for server admins.

Common Aloft Dedicated Server Problems and Fixes

Most Aloft server problems come from one of four areas:

• Discovery
• Networking
• Save handling
• Headless launch arguments

Below is a practical troubleshooting matrix.

Troubleshooting Matrix

The following table highlights the most common Aloft dedicated server issues, their likely causes, and the practical fixes administrators use to resolve them.

Server Not Appearing in Browser

Some providers report delayed browser listing in their environments. If listing is delayed, confirm that the server has fully started, verify the current room code, and recheck the browser after a short wait.

Also confirm:

• isvisible#true# is enabled for public listing
• The networking settings documented for the deployment are correct
• The player is looking in the correct region

Players Cannot Connect

If the browser fails, use the room code from:

ServerRoomCode.txt

Current hosting documentation recommends friend-code joining and notes that the code can change after server restarts.

Server Not Saving Progress

If progress seems lost after a restart, verify the active save location, selected world, account, completed writes, and compatibility. Use the live Data01 or data06 Saves directory and preserve the current target before restoring a snapshot.

Shader Warnings or Headless Errors

Use:

disablevideo#true#

This provider-documented flag may reduce shader-related noise in some no-GUI runs; preserve the full log and fix underlying errors before lowering verbosity.

Self-Hosting vs Aloft Dedicated Server

An Aloft dedicated server is worth it when your group wants a shared world that can stay online without one player keeping the game client open.

Self-Hosting on a Home PC

Self-hosting makes sense when:

• Your group is small
• The host can stay online
• You are comfortable managing saves, ports, and updates manually

Renting a Server

A hosted gaming server makes more sense when:

• You want 24/7 uptime
• You want easier recovery and file access
• Multiple players join regularly
• The host PC should not carry the whole session

Deploy High-Performance Game Servers With RedSwitches

An Aloft dedicated server gives your group a persistent world without requiring one player to keep the game client open.

Once the PowerShell scripts and launch parameters are configured, the room code is generated, and save backups are in place, the server can support up to eight players.

However, the hosting system and server process must remain online for the world to stay accessible.

Self-hosting may work for a small group, but maintaining consistent uptime becomes harder when the host PC is restarted, disconnected, or needed for other tasks.

Dedicated infrastructure provides isolated resources and greater control over server files, updates, security, and backups.

RedSwitches provides dedicated servers with full root access, high-performance processors, SSD or NVMe storage, DDoS protection, and multiple global data center locations.

You can choose infrastructure closer to your players and manage the Aloft server environment without competing for resources with other users.

With a reliable host and regular save backups, your crew can spend less time troubleshooting and more time exploring, building, and keeping its shared Aloft world online.