GuidesOnly show guides for your app
GuidesGuidesGive your servers a private uuid.internal address so a bot can reach its database or cache without exposing anything to the internet.
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.
| At a glance | |
|---|---|
| You need | Two or more Falix servers whose nodes support internal networking |
| Plan | All plans |
| Time | Ten minutes |
When you enable internal networking, the server gets:
<server-uuid>.internal — a name your other servers can connect to.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.
The model is: enable on each server, then connect them as peers.
uuid.internal address appears (click to copy).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.
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.
Enable internal networking on both servers and connect them as peers.
Copy the Redis server's internal address, e.g. a1b2c3d4-....internal.
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.internalname or by its10.xIP — the name is easier to read and doesn't change.
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.
| Action | Permission |
|---|---|
| View the tab and addresses | allocations read |
| Enable / disable, internal-only | allocations create |
| Connect / remove peers | the internal-network allocation permission |
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.
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.