Networking

Every BareMeta server lives inside one of your projects. Servers in the same project share an internal private network and can talk to each other directly. Servers in different projects are isolated from each other by default — the only way they reach each other is through explicitly exposed public connectivity.

How networking works

When you create a server on BareMeta, two things happen:

• The server joins your project's private network, where it gets an internal IP like 10.10.x.y that only other servers in the same project can reach.
• During beta, new servers are private-only by default unless you select public IPv4 during creation and capacity is available.

This gives you a normal VPS path for web servers while still letting backend/database/internal servers launch without inbound public exposure.

VPN access during closed beta

During beta, WireGuard VPN is the recommended secure way to reach private BareMeta servers from your own device. Public IPv4 is available for servers that request it during creation, subject to limited address capacity.

What is WireGuard?

WireGuard is a lightweight VPN. It creates an encrypted tunnel between your device and BareMeta, so your laptop or workstation can reach your private servers as if it were connected to the same private network.

Use it when your server does not have a public IPv4 address, or when you want to manage private services such as SSH, databases, and internal dashboards without exposing them to the internet.

During beta, VPN credentials are issued per user. Creating them requires your account to belong to at least one active billable organisation with a saved payment method. If you belong to multiple organisations, the VPN is still a single user credential rather than an organisation or project-specific credential.

The VPN gives your device an address in the 10.200.0.0/24 range and routes BareMeta private networks such as 10.10.x.0/24 through the tunnel. Once connected, use the private IP shown in the dashboard to reach your server.

# Check the tunnel on Linux
sudo wg show

# Check the BareMeta VPN gateway
ping -c 3 10.200.0.1

# Check your project gateway and server private IP
ping -c 3 10.10.101.1
ping -c 3 10.10.101.19

Projects are private networks

A project on BareMeta is more than a folder for organising your servers. It's also a network boundary:

• Each project gets its own private subnet (a block of internal IPs in the 10.10.x.0/24 range).
• Every server you create in that project gets an internal IP from that subnet.
• Servers in the same project can reach each other on those internal IPs without any firewall configuration.
• Servers in different projects cannot reach each other on internal IPs — only via their public IPs.

Servers in the same project

If you create three servers — say web-01, db-01, and cache-01 — in the same project, they'll get internal IPs that look something like:

web-01    10.10.42.10
db-01     10.10.42.11
cache-01  10.10.42.12

From web-01, you can reach the database directly:

# From web-01
psql -h 10.10.42.11 -U appuser mydb

# Or via Redis on cache-01
redis-cli -h 10.10.42.12

This traffic stays entirely inside your project's network. It doesn't touch the public internet and doesn't need any firewall rules to be opened. It just works.

Servers in different projects

Each account starts with a single project named default, and all your servers go in there. That works for the vast majority of workloads — frontend, backend, database, cache all happily sharing one private network.

If you need a second project for environment separation (e.g. Staging vs Production) or to isolate a sensitive workload, contact support during the closed beta and we'll provision it for you. Once you have multiple projects, servers in different projects cannot reach each other on internal IPs — the platform blocks all internal traffic between projects by default. Communication between them happens via public IPs, the same way an external service would reach them.

Public IPs and what they mean

An assigned public IPv4 address is dedicated to that server while the assignment remains active. The dashboard will only show a public address once it is actually assigned; launch-time assignment may appear shortly after first boot rather than instantly.

If you later want to swap public IPs between servers (e.g. blue/green deployments where you keep DNS pointing at the same IP), use the Reassign action in the Public IPs tab. To return an IP to the pool, use Release.

Practical implications:

• The address is dedicated while assigned. You can run services on standard ports such as 22, 80, and 443 once firewall and routing for that assignment are active.
• Inbound access still needs firewall rules. Add BareMeta firewall/security-group rules and configure your server's own firewall before exposing services.
• Reverse DNS is per-server. If you need a custom PTR record (for mail, for example), contact support.
• If the server is destroyed, the IP is reclaimed. Don't hard-code public IPs into long-lived configs without expecting churn — use DNS.
• Abuse is attributable. If we receive an abuse report tied to one of your IPs, we know which server (and which customer) it came from. Behave accordingly.

What's open and blocked by default

Inbound and outbound traffic on your server is governed by two things: BareMeta's platform-level rules (which apply to all servers), and the host-level firewall you configure inside your server (UFW, etc.).

Platform-level — applies to every server

Host-level — your server's own firewall

Once a server is reachable from the internet, host-level firewalling is still your responsibility. Enable UFW with sensible defaults and open only the ports your workload needs. We cover this in detail in Securing your server.

Sending email from your server

Outbound traffic on port 25 (the port mail servers use to talk to each other) is blocked by default. This is standard practice across every reputable cloud provider and protects the IP reputation of the platform from compromised servers being used for spam.

The right way to send mail

Use a transactional email relay. They handle the actual mail delivery from their own warmed-up reputation IPs, which gives you better deliverability than any cloud server's IP can ever achieve. Your server connects to the relay over port 587 or 465 (both open) using credentials you configure.

Popular options:

• Mailgun, SendGrid, Postmark, AWS SES, SMTP2GO — all offer free or low-cost tiers
• Scaleway TEM, Brevo (formerly Sendinblue) — European alternatives

Configure your application or local mail daemon to connect to the relay's submission endpoint:

# Example — Python smtplib via Mailgun
import smtplib
from email.mime.text import MIMEText

msg = MIMEText("Hello from BareMeta")
msg["Subject"] = "Test"
msg["From"] = "you@yourdomain.com"
msg["To"] = "recipient@example.com"

with smtplib.SMTP_SSL("smtp.mailgun.org", 465) as smtp:
    smtp.login("postmaster@mg.yourdomain.com", "your-api-key")
    smtp.send_message(msg)

If you genuinely need direct port 25 access

Some legitimate use cases (e.g. running a mail server for an established domain with proper SPF/DKIM/DMARC and a clean sending history) need direct outbound :25. Contact support with details of your domain and intended sending volume — we can review and unblock case-by-case.

DDoS protection

BareMeta is backed by a UK datacentre provider with 24/7 onsite operations, redundant rack power, diverse connectivity, and provider-level network protection.

Baseline on-demand network-layer DDoS mitigation is included via our upstream datacentre provider, subject to provider limits and fair use. It is designed for volumetric attacks against the network path before traffic reaches your server.

Higher-capacity always-on protection may be available by agreement for workloads that need stronger guarantees. Exact thresholds, pricing, and filtering behaviour depend on the datacentre package active on your service.

Common setups

Single-server app

One server, one project. The default. Everything runs on one machine, you reach it via its public IP, you configure UFW to expose just :22 + :80 + :443. Simplest possible setup.

Web tier + database tier

Two servers in the same project. Web server has UFW open on :22 + :80 + :443. Database server has UFW open on :22 only — and the database listens on its private IP for connections from the web server. The database is invisible from the public internet.

# On db-01, configure PostgreSQL to listen on the private IP only
# In /etc/postgresql/16/main/postgresql.conf
listen_addresses = '10.10.42.11'

# In pg_hba.conf — only allow connections from the web tier's private IP
host    mydb    appuser    10.10.42.10/32    scram-sha-256

Staging vs production

Two projects: Staging and Production. Identical server layout in each. Servers across projects can't talk internally — staging accidents can't bleed into production data. If your CI needs to deploy from one to the other, do it over public IPs with proper auth.

Multi-customer separation

One project per customer. Each customer's data lives in its own private network, completely isolated from other customers at the platform level. A compromise in one customer's environment cannot scan or pivot to another customer's servers internally.