Iso2God FTP Upload to Aurora, Freestyle Dash and XeXMenu
Iso2God FTP upload removes the USB stick from the workflow entirely: the Windows GUI holds your console’s FTP settings and its built-in uploader sends each finished GOD package to the console in the background, straight after conversion. This guide sets up both ends — the GUI’s FTP configuration and the FTP servers inside Aurora, Freestyle Dash and XeXMenu — and explains the fork’s predefined Hdd1, Usb0 and Usb1 destination paths.
How the built-in uploader works
FTP support is not a fork invention: the decompiled original code already contains a Settings form for FTP configuration and a background FtpUploader that uploads finished packages. What the r4dius fork adds is control over where the upload lands — you can choose the destination path instead of accepting a fixed one, with predefined targets for the console’s storage devices: Hdd1 (the internal hard drive), Usb0 and Usb1 (the first and second USB devices). The fork can also delete the source ISO or the local GOD copy after a successful upload, which keeps a conversion PC from filling with duplicates — leave those options off until your first upload is proven on the console.
Step 1: Turn on the console-side FTP server
The PC can only upload to a console that is listening. All three common targets run FTP servers, with the same underlying idea:
- Aurora — enable the FTP server in Aurora’s settings and note the console’s network IP address shown in the dashboard. Aurora is the current default dashboard, so this is the setup most users need.
- Freestyle Dash (FSD) — FSD likewise includes an FTP server; enable it in settings and read the console IP from its network display.
- XeXMenu — the file-manager homebrew also exposes FTP access, which suits stock-dashboard-plus-XeXMenu setups where no full custom dashboard is installed.
Credentials for these homebrew FTP servers are set by the dashboard or its documentation defaults — configure them on the console side first, then mirror exactly the same username, password, IP and port into Iso2God. A wired Ethernet connection for the console is worth the cable: GOD packages are gigabytes, and console Wi-Fi of that era is the usual bottleneck.
Step 2: Configure FTP in the Iso2God GUI
- Open the GUI’s Settings and find the FTP section (get the tool itself from the download page).
- Enter the console IP address, FTP port, username and password exactly as configured on the console.
- Choose the destination: pick the predefined Hdd1, Usb0 or Usb1 target, or set a custom path. For stock-dashboard visibility, aim the upload at the Content structure for the game —
Content\0000000000000000\<TitleID>\00070000\on that device; for Aurora or FSD, any folder inside your scan paths works. - Run one single-game conversion and let the uploader finish before queuing a batch. Prove the path, the credentials and the scan with one title first.
Step 3: Verify on the console, not on the PC
One practical sequencing tip before the verification step: convert and upload a single representative game first — ideally not the largest title in your library — and carry it all the way to a successful launch. That first end-to-end pass calibrates everything at once: the destination path, the scan behaviour and your own expectations of upload speed on your network.
An upload that completes without an error message is only half verified. On the console, run a content scan in Aurora or FSD (or restart the dashboard) and confirm the game appears, then launch it and play past a save point. The failure modes mirror manual copying — see the transfer guide — because FTP moves the same two pieces: if the header file arrives without its full .data folder (an interrupted upload is the usual cause), the console reports corrupted content and the fix is to upload the pair again, completely.
Network basics that decide whether uploads feel fast or broken
Three unglamorous details account for nearly every FTP complaint in this workflow. First, keep the PC and the console on the same local network segment: an upload routed through a guest network, a VPN tunnel or a double-NAT arrangement may connect and then crawl or drop mid-package, and a dropped GOD upload leaves a partial .data folder that the console quite correctly calls corrupted. Second, give the console a stable address — a DHCP reservation in the router, or a static IP set on the console — because the GUI stores the address you type, and a console that changes IP after every reboot makes a saved configuration look randomly broken. Third, prefer wired Ethernet at both ends for library-sized sessions: a single game forgives slow Wi-Fi, but dozens of packages turn a weak wireless link into an evening of babysitting retries. None of this is Iso2God-specific — it is simply what moving gigabytes through a 2005-era console’s network stack demands, and ten minutes spent on it before the first upload pays for itself on every upload after.
FTP versus USB: which should you use?
| Situation | Better route | Reason |
|---|---|---|
| One game, console already networked | FTP upload | No drive handling; the GUI can send automatically after converting. |
| A whole library migration | Direct drive copy, or FTP over wired Ethernet | Sustained throughput and fewer round trips for dozens of packages. |
| Console not on the network | USB transfer | The Content-path USB route needs no network setup at all. |
| Multi-disc release | Either — with the install-disc rules applied first | Disc handling is decided at conversion time, not transfer time. |
The new alternative: iso2god-next also offers FTP
In release news: iso2god-next, a GTK4 continuation of the iso2god-rs line that appeared in October 2026, also advertises FTP upload to Aurora, Freestyle Dash, XeXMenu or any FTP server, alongside converting extracted folders directly. It is days old at the time of writing and its own release notes say the non-Linux builds have had little testing on real machines, so treat it as a promising development to watch rather than the default recommendation — the GUI-plus-FTP workflow above is the proven one. Its arrival does confirm the direction of travel: conversion and upload are merging into one step across the whole tool family.
Frequently asked questions
Why does the upload finish but the game never appears?
Almost always the destination path. If the package landed outside the stock dashboard’s Content path and outside every Aurora/FSD scan path, it is on the drive but undiscovered. Check where the predefined device path actually points, move or re-upload the pair into a scanned location, and scan again.
Should I enable ‘delete after upload’?
Only after several proven uploads, and only the local-copy option at first. Deleting the source ISO automatically removes your easiest reconversion path; the fork offers the option for tidiness, not as a recommended default for new setups.
Can iso2god-rs upload by FTP too?
No — upstream iso2god-rs is conversion only, with no FTP and no GUI. Use the Windows GUI’s uploader, a general FTP client pointed at the same console server, or watch the iso2god-next project. The conversion side of rs is taught in the iso2god-rs guide.
Does FTP change anything about multi-disc games?
No. Both discs upload as separate packages with the same Title ID logic, and swapping behaviour (Aurora/FSD auto-swap, or DashLaunch autoswap for XeXMenu setups) is a console-side matter covered in Multi-Disc Games with Iso2God. More guides sit in the Tutorials hub.