Internal Network — private links between your servers

Sometimes one of your servers needs to talk to another — a Discord bot reaching its database, a web app hitting a Redis cache, a proxy in front of backend game servers. You could do that over public ports, but then anyone on the internet can knock on the door too. The Internal Network tab on the Network page is the private alternative: it gives each server an address that only your own Falix servers can reach. Open Network from your server menu and pick Internal Network.

What you get

When you enable internal networking, the server gets:

• A private address: <server-uuid>.internal — a name your other servers can connect to.
• A private IP on an internal network (a 10.x.x.x WireGuard address), assigned automatically.

Nothing about this is public. The .internal name doesn't resolve on the open internet — only from your other Falix servers that you've linked as peers. A public port is still a public port; this simply adds a second, private way in.

🎯 Good to know: If the tab says internal networking isn't available on this node, that server's host doesn't offer it yet. Most nodes do; if yours doesn't, contact support or fall back to a public port.

Set it up

The model is: enable on each server, then connect them as peers.

1. Enable it on the first server. Open Network → Internal Network → Enable. The server's uuid.internal address appears (click to copy).
2. Enable it on the second server the same way.
3. Connect them as peers. On either server, open Manage Peers. Your other servers that have internal networking on show up as candidates — press Connect on the one you want. The link is two-way immediately; you don't repeat it on the other side.
4. Restart any server whose networking you just changed, so it picks up the new setup.

A peer only appears as a candidate if it also has internal networking enabled and you own it (or you're a sub-user on it with the internal-network permission). To undo a link, open Manage Peers and press Remove — or Disable internal networking entirely to drop all of that server's links and release its private IP.

A real example: a bot and its Redis cache

Say you run a Discord bot on one server and a Redis app on another (see Run a standalone database server). You don't want your Redis exposed to the internet — so keep it private.

1. Enable internal networking on both servers and connect them as peers.

2. Copy the Redis server's internal address, e.g. a1b2c3d4-....internal.

3. In the bot, connect to Redis at that address on the Redis server's port, using the password from its Redis Password variable:

   import { createClient } from 'redis';
   
   const client = createClient({
     url: `redis://:${process.env.REDIS_PASSWORD}@a1b2c3d4-....internal:6379`
   });
   client.on('error', (e) => console.error('Redis error', e));
   await client.connect();
   console.log('Connected to Redis privately');

The port is the Redis server's own allocated port (shown on its Network page), and the password lives in an environment variable, never in code. The same shape works for a MySQL/Postgres/Mongo app, or for a bot that keeps its data on a separate database server — see where bots store data and Redis caching.

💡 Tip: You can address a peer by its uuid.internal name or by its 10.x IP — the name is easier to read and doesn't change.

Internal-only mode (advanced)

Once internal networking is on, there's an Internal Only toggle. Flip it and the server's public ports are hidden — it becomes reachable only from your other servers, not the internet at all. This is how you lock down a database or an internal API that should never take outside traffic. It takes effect after a restart, and the panel warns you clearly, because a web server in internal-only mode will look "down" to the outside world (that's the point). Turn it back off to expose the ports again.

Who can use it

These are set per sub-user on the Sub-users page. Enabling or disabling is logged to your server's Activity log, so you can always see who changed it.

Troubleshooting

• A server isn't in the peer list — it needs internal networking enabled first, and you need to own it (or hold the internal-network permission on it). Enable it there, then look again.
• The connection times out — restart both servers after linking them; confirm the target app binds 0.0.0.0 on its port (not 127.0.0.1), and that you're using the peer's port, not a made-up one.
• My site went "down" after a change — you probably turned on Internal Only, which hides public ports by design. Turn it off and restart.
• "Not available on this node" — that host doesn't offer internal networking; use a public port or ask support.

Next steps

• The Network page, end to end
• Run a standalone database server
• Redis caching for your app