Make FlightGear portable from an extracted archive, keep settings and scenery on one drive, and prepare aircraft and route tiles for offline play.
Yes. FlightGear can run as a portable installation from a fully extracted, writable archive on an internal or removable drive. It can also be played offline, but only after the aircraft, airport and navigation data, and scenery needed for the flight have been stored locally and their paths configured.
How do I make FlightGear fully portable?
A fully portable FlightGear setup keeps the application, user settings, downloads, TerraSync repository and manually installed content on the same drive.
- Choose the correct archive build. The executable must match the operating system and processor of every host computer on which you intend to use it. Our guide to choosing and unpacking FlightGear PC packages explains the difference between an installer and an extractable archive.
- Extract the complete archive. Place it in a writable directory on an internal disk, external SSD or USB drive. Do not run FlightGear from inside the compressed archive, and do not rearrange its executable and base-data directories.
- Create separate writable folders. At the archive root, create folders such as
UserData,Downloads,TerraSync,AircraftandScenery. The names are optional, but separating them makes upgrades and fault-finding much easier. - Set
FG_HOMEbefore anything starts. Use an environment variable or--fg-hometo place preferences and user state inUserData. This must happen before opening either the Launcher or the simulator; changing it afterwards does not move files already written to the host profile. - Assign each content path correctly. Use
--download-dirfor Launcher-managed downloads,--terrasync-dirfor the TerraSync repository,--fg-sceneryfor manually installed scenery and--fg-aircraftfor manual aircraft. These settings serve different purposes and should not be treated as interchangeable. - Test portability. Start through the portable script, change a harmless preference, close FlightGear and confirm that the portable folders were updated. If the drive may receive another letter or mount point, remount it there and test again before relying on the installation away from home.
The extracted package should normally locate its base data relative to the executable. Set FG_ROOT or pass --fg-root only if automatic detection fails; it must identify the supplied base-data directory containing core files such as defaults.xml.
Windows portable startup script
Place this batch file beside the archive’s bin and base-data directories. It derives every path from the batch file’s location, so it does not contain a fixed drive letter.
@echo off
setlocal
set "APP_DIR=%~dp0"
set "FG_HOME=%APP_DIR%UserData"
for %%D in ("%FG_HOME%" "%APP_DIR%Downloads" "%APP_DIR%TerraSync" "%APP_DIR%Scenery" "%APP_DIR%Aircraft") do if not exist "%%~D" mkdir "%%~D"
"%APP_DIR%bin\fgfs.exe" --launcher "--fg-home=%FG_HOME%" "--download-dir=%APP_DIR%Downloads" "--terrasync-dir=%APP_DIR%TerraSync" "--fg-scenery=%APP_DIR%Scenery" "--fg-aircraft=%APP_DIR%Aircraft"
endlocal
If the archive places fgfs.exe somewhere other than bin, change only the executable path on the launch line. Always start through this batch file rather than opening the executable directly.
POSIX portable startup script
For an extracted Linux or other POSIX-style build exposing bin/fgfs, save this as a shell script at the archive root and make it executable.
#!/bin/sh
APP_DIR=$(CDPATH= cd -P "$(dirname "$0")" && pwd)
FG_HOME="$APP_DIR/UserData"
export FG_HOME
mkdir -p "$FG_HOME" "$APP_DIR/Downloads" "$APP_DIR/TerraSync" "$APP_DIR/Scenery" "$APP_DIR/Aircraft"
exec "$APP_DIR/bin/fgfs" --launcher "--fg-home=$FG_HOME" "--download-dir=$APP_DIR/Downloads" "--terrasync-dir=$APP_DIR/TerraSync" "--fg-scenery=$APP_DIR/Scenery" "--fg-aircraft=$APP_DIR/Aircraft"
Package layouts differ, particularly for application bundles, so adjust the final executable path when necessary. The path derivation and data options remain the same.
FG_HOME and --fg-home select the same category of user data; the examples set the environment first and pass the matching option explicitly so the Launcher and simulator receive the same location. Even with these scripts, file paths saved separately inside the Launcher may remain absolute and need updating after the drive letter or mount point changes.
Which FlightGear folders must stay on the portable drive?
Every folder needed to start FlightGear or preserve its state must remain on the removable drive if the installation is to be self-contained.
| Content | Purpose | Setting or option |
|---|---|---|
| Application and base data | The executable, built-in aircraft and core simulator data in their supplied archive structure | Normally detected automatically; use FG_ROOT or --fg-root only when required |
| User settings and state | Preferences, saved configuration and user-specific data, including some navigation-data additions | FG_HOME environment variable or --fg-home |
| Downloaded content and cache | Content obtained through FlightGear’s download facilities | Corresponding Launcher setting or --download-dir |
| TerraSync repository | Terrain, objects and airport scenery fetched by TerraSync | Corresponding TerraSync setting or --terrasync-dir |
| Manually installed aircraft | A parent folder containing individual aircraft directories | Launcher aircraft search path or --fg-aircraft |
| Manually installed scenery | A scenery root containing directories such as Terrain, Objects or Airports | Launcher scenery search path or --fg-scenery |
A common mistake is to use --download-dir as though it were a manual scenery search path. It is a download destination, while --fg-scenery tells FlightGear where to search for manually installed scenery. Some releases place TerraSync beneath the download directory by default, but assigning --terrasync-dir explicitly removes that ambiguity.
Keep a separate FG_HOME for substantially different FlightGear releases. Reusing one user directory can carry incompatible preferences or cached state between copies. For aircraft and scenery package structure, see our instructions for placing FlightGear add-ons in separate writable folders.
Can I play FlightGear offline?
Yes, FlightGear can be played offline once the chosen aircraft, airport and navigation data, and all required scenery tiles are available locally.
- Install and open the aircraft while online. Confirm that the intended aircraft is present on the portable drive and loads without requesting another download. Include any aircraft dependencies supplied as separate content.
- Check airport and navigation data. The base package includes the data expected by that FlightGear build, while separately updated data may live under the portable user directory. Follow our guidance on keeping FlightGear navigation data with the correct
FG_HOMEif you have installed an update. - Download the complete route area. While connected, acquire and verify scenery for the departure, destination, alternates and route corridor. Loading only the departure airport does not guarantee that TerraSync has stored tiles around the destination.
- Select the local scenery paths. Make sure the portable TerraSync repository is assigned with
--terrasync-dirand any manual scenery roots are included through--fg-scenery. - Perform an offline check. Disconnect the network, load the intended aircraft at both ends of the route and inspect the surrounding terrain and airports. This catches missing tiles, incomplete downloads and absolute paths before travel.
Without a connection, live online weather and multiplayer will be unavailable, and TerraSync cannot fetch missing scenery. Select a non-online weather mode if needed. Missing tiles may produce absent terrain, low-detail fallback scenery or water where land should be.
Scenery consists of many small files, so storage speed matters. A low-cost USB flash drive can cause pauses during terrain loading; an external SSD is preferable for a large TerraSync repository. Keep enough free space for cache growth and confirm that the device remains writable.
Why does a portable copy lose settings, aircraft or scenery?
Portable FlightGear problems usually come from a bypassed startup script, an incorrect directory level, an absolute saved path or a drive that cannot be written.
- Settings return to defaults: FlightGear was started directly, or
FG_HOMEwas assigned after the Launcher opened. Close every FlightGear process and restart through the portable script. - Files appear in the host profile: another shortcut or file association bypassed the script. Copy any wanted settings only after backing up both user-data folders.
- Base data cannot be found: preserve the extracted archive structure and check that
FG_ROOTor--fg-rootpoints to the base-data directory containingdefaults.xml, not merely to the drive root. - An aircraft is missing:
--fg-aircraftshould point to the parent directory containing the aircraft folders, not to an individual configuration file. - Terrain is absent or becomes water: check the manual scenery root, the TerraSync directory and whether the required tiles finished downloading. A path one directory too high or too low will not work.
- The setup breaks after moving computers: the script recalculates its own paths, but the Launcher may still contain an absolute drive letter or mount point saved in another field. Update those entries or replace them with script-supplied options.
- Changes are not saved: the medium may be read-only, full, disconnected or blocked by host security policy. Confirm write access to
UserData,DownloadsandTerraSync.
Will the same portable FlightGear copy run on every computer?
No. Portability avoids a conventional installation, but it does not turn one FlightGear build into a cross-platform or hardware-independent application.
A Windows executable remains a Windows executable; it will not become a Linux or macOS application because it is stored on a removable drive. The processor architecture must also match, and the host still needs suitable graphics drivers, memory and storage. Check our FlightGear operating-system and hardware guidance before preparing a drive for several computers.
The host may also block programs launched from removable storage. On POSIX systems the drive can be mounted with execution disabled, while managed computers may apply application-control rules or deny write access. Moving the simulator does not bypass those restrictions.
Controllers, display layouts and rendering settings may need separate profiles for machines with different hardware. The operating system can also retain recent-file entries, temporary files or security metadata, so a portable installation should not be treated as a guaranteed zero-trace mode.