Build a verifiable PSO hosting workflow before opening any service to remote players
newserv is a self-hosted game server, proxy, and reverse-engineering tool for Phantasy Star Online. This guide explains how to plan the installation, identify the required project documentation, prepare configuration and game data, start the service, verify it locally, and determine whether it is ready for remote access. The available project evidence does not specify reproducible build commands, configuration filenames, default listener ports, or listener protocols, so we do not invent them. After local operation is confirmed, we show how to collect the facts needed to choose the correct Localtonet tunnel without exposing an unverified or unintended service.
📋 What's in this guide
What newserv is and what this deployment involves
newserv is an actively maintained Phantasy Star Online project that can operate as a game server, a proxy, and a collection of reverse-engineering tools. Those roles should not be treated as interchangeable. A game-server deployment accepts game clients and provides server-side behavior. A proxy deployment handles traffic differently and may need to reach another service. Reverse-engineering utilities may be run only when needed and should not automatically be exposed to a network.
The project documentation identifies dedicated sections for server setup, connecting clients, compatibility, client patch directories for PC and Blue Burst, user accounts, quests, item tables and drop modes, cross-version play, server-side saves, Episode 3 features, memory patches, proxy use, chat commands, and a REST API. This indicates that a complete deployment involves more than launching one executable. The applicable configuration depends on the PSO client version and the newserv role you intend to run.
Begin by writing down the intended scope. Identify the PSO edition or editions that should connect, whether newserv will be the game server or a proxy, whether accounts and server-side saves are required, and which optional features are actually needed. This avoids copying a broad configuration into production when a narrower deployment would be easier to test and protect.
The supplied project material confirms what newserv is and points readers to its Server setup and How to connect sections. It does not include the contents of those sections, exact prerequisites, build commands, executable names, configuration paths, default credentials, listener addresses, ports, or transport protocols. This article therefore provides a safe, evidence-gated workflow rather than fabricating commands that could be wrong for the current release.
Prepare the newserv host
Choose a machine that can remain available while players are connected. The host should have enough local storage for the project, configuration, game data, logs, quests, accounts, and any server-side saves used by your deployment. Because the supplied evidence does not define minimum processor, memory, or storage requirements, size the host through local testing rather than relying on invented minimums.
The current project repository contains CMake configuration and a Dockerfile, and the project notes that newserv works on Windows but is difficult to compile there. A release dated September 2, 2026 is labeled for macOS and Windows and contains release assets. These facts establish that multiple deployment paths exist, but they do not establish exact build or container commands. Select one supported path from the complete instructions for the exact revision you intend to use.
| Preparation decision | What is established | What must be confirmed |
|---|---|---|
| Release asset | A September 2, 2026 release is labeled for macOS and Windows. | Confirm the correct asset, architecture, extraction procedure, bundled files, and startup instructions. |
| Source build | The repository contains CMake configuration. | Confirm compiler versions, dependencies, CMake options, build commands, and the resulting executable location. |
| Container deployment | The repository contains a Dockerfile. | Confirm the supported image build procedure, mounts, environment, published ports, persistence, and startup command. |
| Windows compilation | The project states that compiling on Windows is difficult, although newserv works there. | Confirm whether a release asset is preferable to a local Windows build for your selected revision. |
Create an installation record
Record the newserv version or commit before changing configuration. Keep a copy of the original configuration material alongside a separate working copy, but never place passwords, account data, or other secrets in a public repository. If you use a release asset, record its release identifier. If you build from source, record the exact revision and the dependency versions used by the successful build.
Also decide where persistent data will live. Account records, server-side saves, installed quests, customized item tables, and logs may need different backup and retention policies. The supplied evidence does not identify their exact paths or formats, so derive those details from the selected revision rather than assuming that paths from an older tutorial remain valid.
Prepare a controlled test network
Carry out the first start on a trusted local network. Do not create router forwarding rules or a public tunnel during the initial installation. Local testing lets you distinguish a newserv configuration problem from a remote connectivity problem. It also gives you an opportunity to inspect every listening socket before deciding which one, if any, should be reachable over the internet.
The project history discusses the risk of malformed traffic and client save corruption in the wider PSO ecosystem. Keep backups of valuable client data and any server-side saves before testing a new server, proxy, patch, quest, or cross-version configuration. Treat experimental clients and reverse-engineering workflows as separate from irreplaceable game data.
Install newserv without guessing commands
The reliable installation procedure must come from the Server setup section associated with the exact newserv revision being installed. The excerpt available for this draft does not contain that procedure. In particular, it does not establish package-manager prerequisites, compiler commands, archive filenames, container arguments, installation directories, or executable names. Reproducing plausible-looking commands would create a tutorial that may fail or, worse, run with an unintended configuration.
Use the following installation sequence as a verification framework. At each stage, complete the project-provided instruction for your selected release and capture the result in your deployment notes.
Choose one documented installation path
Select the release-asset, source-build, or container path supported by the complete documentation for your platform and exact revision. Do not combine files or commands from unrelated releases.
Complete the project’s Server setup procedure
Install only the prerequisites named by the project, obtain the expected files, and follow its setup order. Preserve all command output so missing dependencies or generated-file errors remain available for troubleshooting.
Inventory the installed material
Identify the executable or container entry point, configuration files, static and system data, writable state, logs, account storage, save storage, and optional content directories as documented by the selected revision.
Start newserv in a local-only test context
Use the documented startup method without adding internet exposure. Capture the complete startup output and check it for missing files, invalid configuration, permission failures, and listener information.
Follow the matching How to connect instructions
Apply only the client connection and patching procedure documented for the PSO version under test. Keep an untouched client copy where practical so a failed patch or configuration change can be reversed.
A successful compilation or extraction is not the same as a successful server deployment. The installation is complete only when newserv starts with the intended configuration, the expected listeners are present, a supported client reaches the service locally, and the resulting account or session behavior matches the chosen mode.
Configure the intended PSO environment
Configuration should begin with compatibility, not optional features. Determine which client version will be the first test target and complete the corresponding connection procedure. If multiple versions will eventually be supported, add them one at a time after the first client works. This makes it much easier to associate a failure with a particular patch, listener, game-data set, or cross-version option.
Accounts and persistence
The newserv documentation includes a section for user accounts and another for server-side saves. Review both before inviting players. Establish how accounts are created, how access is revoked, which data is authoritative, and what must be backed up. Do not assume a default username or password, and never expose a deployment that still has sample or shared credentials unless the current documentation explicitly requires them for a temporary local test.
If server-side saves are enabled, test restoration before relying on backups. A backup that has never been restored is only an unverified copy. Stop or quiesce the service according to the project’s instructions before copying state that may be actively written. The available evidence does not define whether live copying is safe, so do not assume it is.
Quests, item tables, and gameplay options
The project supports installing quests and documents item tables and drop modes. Introduce these changes after the base server works. Keep each custom quest or data change associated with its source, version, and installation date. If startup or gameplay breaks, revert the latest change and retest before modifying networking.
Cross-version play and Episode 3 features deserve isolated testing because they add compatibility variables beyond ordinary connectivity. Similarly, memory patches, client functions, and the DOL loader should be treated as client-specific or advanced functionality. Do not enable every available feature merely because it exists.
REST API and administrative surfaces
A REST API section is listed in the project documentation, but the supplied evidence does not establish whether it is enabled by default, which address it binds to, its port, its authentication model, or its available operations. Inspect the full documentation and active configuration before using it. An API or administrative listener should not be included in the public game-service tunnel unless remote access is explicitly required and protected.
A newserv process may have game, proxy, API, or diagnostic responsibilities, but the supplied evidence does not identify their network layout. Determine the purpose of each listener and expose only the minimum set required by the supported client workflow. Keep management and diagnostic interfaces private unless their documentation provides an appropriate access-control design.
Verify newserv on the local network
Local verification must happen before Localtonet integration. Start by reading the complete startup output. Confirm that newserv loads the expected configuration and required data without fatal errors. Record every listener address, port, and protocol reported by the application. If the logs do not identify these properties, inspect the host’s listening sockets using an operating-system tool appropriate to that host.
Do not infer transport from the word “game,” “server,” “proxy,” or “REST.” A game workflow can involve TCP, UDP, or multiple connections, while an HTTP-based API is separate from the gameplay protocol. The tunnel decision must be based on observed and documented behavior.
Run a client connection test
Follow newserv’s How to connect instructions for the selected PSO version. First test from the host itself if that workflow is supported. Then test from another device on the same trusted LAN. A second-device test is valuable because it detects loopback-only binding, host firewall restrictions, and incorrect client addresses that a same-machine test may hide.
A connection screen alone is not sufficient proof. Complete enough of the workflow to confirm that the client reaches the intended server role, authentication behaves as configured, a game session can be entered, and expected state is retained. If server-side saves are enabled, reconnect and confirm persistence using test data rather than valuable production characters.
Build a listener inventory
| Fact to record | Why it matters | Acceptable evidence |
|---|---|---|
| Local IP address | Determines what address the Localtonet client must be able to reach. | Application output, documented configuration, or host socket inspection. |
| Port number | Each tunnel target needs the actual local service port. | Current newserv documentation, active configuration, or observed listener. |
| Transport protocol | TCP, UDP, and combined requirements use different tunnel choices. | Project documentation plus network observation during a successful local session. |
| Listener purpose | Prevents an API, diagnostic service, or unrelated proxy from being exposed accidentally. | Configuration comments, documentation, and behavior during testing. |
| Client-visible address behavior | Some applications advertise or redirect clients to another address or port. | A complete local connection sequence and, if needed, a packet capture on your own test network. |
If the initial connection reaches newserv but a later game transition fails, investigate whether the client opens a second connection or receives another address from the server. A tunnel for only the first observed port may be incomplete. Do not add random ports until the error disappears. Identify the documented or observed connection sequence and expose only what that sequence requires.
Add Localtonet only after local verification
With Localtonet, the client application on the newserv host, or on another device that can reach it, establishes an outbound connection to our relay. This can provide a public host and port without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The tunnel remains available only while the selected Localtonet client is connected and the tunnel is running.
There is intentionally no single protocol recommendation in this draft. The available newserv evidence does not identify the required listener ports or whether gameplay uses TCP, UDP, or both. Selecting an HTTP tunnel simply because a REST API exists would also be incorrect because the REST API is not evidence that PSO game traffic is HTTP.
Once the listener inventory is complete, use the standard Localtonet workflow. Install and run our client on a device that can reach the verified newserv listener. Authenticate or select that device using its device-specific token, choose an available relay server or region from the current dashboard, and create the tunnel type that matches the confirmed protocol. Enter the verified local IP address and port, then start the tunnel.
Creating a tunnel does not start it. Use the Start button and confirm that the selected Localtonet device remains connected. Share only the assigned public host and port that correspond to the intended game listener. Stop or delete the tunnel when remote access is no longer required.
A Localtonet auth token identifies a client device and must not be posted in screenshots, logs, tutorials, chat messages, or public configuration repositories. Do not tunnel a newserv REST API, management interface, or diagnostic listener merely because it is reachable from the host. Apply authentication, least privilege, IP restrictions, and application-level access controls wherever the selected service supports them.
Test the public endpoint from a network outside the host LAN. Confirm the Localtonet client is connected, the tunnel is running, and the configured target exactly matches the locally verified listener. Then repeat the same PSO workflow used for local verification. If local play succeeds but remote play fails, keep the known-good newserv configuration unchanged while checking the tunnel protocol, target address, target port, and any additional connection stages.
Operate and maintain the deployment
Treat newserv configuration, game data, accounts, and save data as a maintained service rather than a one-time experiment. Before an update, record the running version and back up all persistent state identified by the project documentation. Review release changes for configuration or data migrations. Test the new revision locally before replacing the working deployment.
Keep logs long enough to investigate failed connections, but avoid publishing logs without reviewing them for account names, addresses, tokens, or other sensitive data. Never store a Localtonet device token in a public issue or newserv repository. If a token is exposed, replace it through the appropriate account workflow rather than assuming deletion of the public text is sufficient.
Restrict operating-system permissions so the newserv process can read the files it needs and write only to its documented state and log locations. Avoid running the service with broader privileges merely to work around a file-permission error. Identify the exact inaccessible path, correct ownership or permissions according to the platform and project guidance, and retry locally.
Keep custom quests, item-table changes, patches, and cross-version options under controlled change management. Introduce one change at a time and maintain a rollback copy. When troubleshooting gameplay, note whether the problem affects all clients, one PSO version, one account, one quest, or only remote connections. That distinction usually narrows the responsible layer.
Troubleshoot by isolating each layer
newserv does not build or start
Verify that the instructions match the selected revision and operating system. Check the first meaningful error rather than the final cascade of failures. A missing dependency, wrong compiler, absent data directory, invalid configuration, or permission problem may produce many later messages. Because exact prerequisites and commands are not present in the supplied evidence, compare the failure with the complete Server setup instructions instead of substituting commands from an older release.
The process starts, but no listener appears
Confirm that the intended server or proxy mode is enabled and that configuration was loaded from the expected location. Review startup output for skipped services or invalid settings. Do not invent a default port. Use current documentation, active configuration, and socket inspection to determine whether the expected listener should exist.
The client cannot connect locally
Recheck the client-specific How to connect procedure, including any patch directory or client configuration required for that PSO version. Confirm the client points to the LAN address of the server rather than an unrelated public address. Test host-local and LAN access separately. If only the LAN test fails, inspect listener binding and host firewall policy.
Login works, but entering a game fails
This may indicate an additional connection, a client-version mismatch, missing game data, or an incompatible feature configuration. Record the newserv log at the moment of failure and inspect the connection sequence. Do not assume that one successful login proves every required port has been identified.
Local access works, but Localtonet access fails
Confirm that the Localtonet device is connected and the tunnel was explicitly started. Check that the tunnel targets the same local IP address and port used by the successful LAN test. Verify that the selected tunnel family matches the confirmed transport. If the client changes ports or receives another endpoint during connection, inventory that behavior before creating any additional tunnel.
The public endpoint stops responding
Localtonet tunnels are available only while the selected client device is connected and the tunnel is running. Check the host, the Localtonet client, the tunnel state, and newserv itself as separate components. A running newserv process does not prove the tunnel is active, and an active tunnel does not prove that its local target is accepting connections.
Frequently asked questions
What is newserv?
newserv is a game server, proxy, and reverse-engineering tool for Phantasy Star Online. Its documentation covers server setup, client connection, compatibility, accounts, quests, item behavior, server-side saves, proxy use, chat commands, and other advanced functions.
Can newserv run on Windows?
The project states that newserv works on Windows but is difficult to compile there. A September 2, 2026 release is labeled for macOS and Windows. Confirm the appropriate installation method and asset for your architecture from the complete instructions for that release.
Which port does newserv use?
The supplied evidence does not establish a default port or a complete port set. Obtain the ports from the current Server setup and How to connect documentation, the active configuration, startup output, and observed listeners. A complete game session may require more than the first connection you observe.
Should I use a TCP, UDP, HTTP, or combined Localtonet tunnel?
Choose only after confirming the protocol of the exact local listener. The supplied newserv evidence does not identify whether the required game connections use TCP, UDP, or both. The presence of a documented REST API section does not mean that PSO gameplay should use an HTTP tunnel.
Do I need router port forwarding with Localtonet?
No inbound router port forwarding is required for the Localtonet workflow. Our client establishes an outbound connection to a relay and provides the public endpoint. The selected device must remain connected, the tunnel must be running, and the device must be able to reach the local newserv listener.
Can I expose the newserv REST API through the same tunnel?
Do not assume so. The supplied evidence only confirms that the project documentation contains a REST API section. It does not establish the API binding, port, authentication, or intended exposure model. Keep administrative interfaces private unless current documentation and your access-control design support remote use.
Why must newserv work locally before I create a tunnel?
Local verification establishes that the installation, configuration, client patching, accounts, game data, listener address, port, and protocol are correct. If remote access is added first, every failure could come from either newserv or the tunnel, making diagnosis slower and less reliable.
Connect your verified newserv listener with Localtonet
After newserv works on your trusted local network and you have confirmed its exact listener address, port, and transport protocol, create a matching tunnel with Localtonet and test it from an external network.
Get Started Free →
