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 a private IP 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.

Once connected, your device can reach your project's private network. Use the private IP shown in the dashboard to reach your server.

# Check the tunnel on Linux
sudo wg show

# Check your server's private IP (shown in the dashboard)
ping -c 3 YOUR_SERVER_PRIVATE_IP

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.
• 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    PRIVATE_IP_A
db-01     PRIVATE_IP_B
cache-01  PRIVATE_IP_C

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

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

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

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.

A server's own public IP is included in its plan price only while it stays on that server. Reassigning it to a different server makes it an additional IP, billed at £3.00/month from the move.

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 follows the instance name. Name a server with a fully-qualified domain name (e.g. mail.example.com) and the platform sets the PTR record for its assigned public IPv4 and tenant IPv6 addresses to that name automatically — manage it from the PTR Records tab in the dashboard.
• 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

Console firewall — rules you manage

The Firewall page lets you add inbound and outbound rules for your servers. The first time you add a rule, the form is pre-filled with a sensible starting set: inbound SSH, plus outbound ICMP and outbound TCP/UDP. Nothing is applied until you submit it, and outbound port 25 stays blocked regardless of your rules.

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
• Brevo and other European providers

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 runs in UK datacentres with network protection at the provider level.

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 limits depend 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 postgresql.conf (path depends on your PostgreSQL version)
listen_addresses = 'PRIVATE_IP_B'

# In pg_hba.conf — only allow connections from the web tier's private IP
host    mydb    appuser    PRIVATE_IP_A/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.