PaaS/container platform with private networking between services (no public IPs)

Fly.io gives you the thing most “modern” platforms hand‑wave away: real private networking between services by default, with no need to hang public IPs off everything just so containers can talk to each other.

Quick Answer: Fly.io is a developer cloud built around Fly Machines—hardware-virtualized containers that launch instantly and sit on a global private network. Your services talk over encrypted private networking by default, and you only expose what actually needs a public entrypoint.

The Quick Overview

• What It Is: A globally distributed container/Machines platform where apps and sandboxes run on VMs with automatic private networking; public IPs are optional and scoped to specific services.
• Who It Is For: Teams that want PaaS-level ergonomics for containers, but with real control over networking, isolation, and latency—without running their own Kubernetes.
• Core Problem Solved: Run microservices, APIs, workers, and sandboxes that talk to each other over a private network, spread across regions, without stapling public IPs or juggling VPN glue.

How It Works

Everything on Fly.io runs on Fly Machines—hardware-virtualized containers that boot fast enough to handle HTTP traffic on demand. Each Fly app lives on Fly.io’s private network. Machines in that app (and in other apps on the same org network) get private IPv6 addresses and can talk to each other directly, encrypted, without crossing the public internet.

You choose which ports, if any, get exposed publicly via Fly Proxy. If a service doesn’t need to be public—like an internal API, a worker, or a database—it just never gets a public service or IP. It still has full access to other services over private networking.

A typical flow looks like this:

1. Deploy your app as a Fly Machine-backed app:
   Use fly launch and fly deploy to build and run your container. By default, it joins your org’s private network and gets a private IP address.

2. Wire up private networking between services:
   Other services in your Fly org use private DNS (<app>.internal, Machine private IPs) to talk directly over the private network. No public IP, no internet round-trip.

3. Optionally expose just the edge you need:
   When a service needs to be reachable from the outside world, you define a [services] block in fly.toml. Fly Proxy terminates traffic at Anycast IPs and forwards it to Machines. Other apps can stay fully internal.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Global Private Networking	Automatically assigns private addresses to Machines and connects apps over Fly.io’s private network.	Services talk to each other securely without public IPs or DIY VPNs.
Selective Public Exposure via Fly Proxy	Lets you expose only specific ports/protocols as public services.	You keep databases, internal APIs, and workers completely private.
Hardware-Isolated Sprites Sandboxes	Runs untrusted or AI-generated code in hardware-isolated sandboxes with their own private network.	Execute risky workloads without noisy neighbors or shared runtimes, still fully connected to your private services.

Ideal Use Cases

• Best for private microservice meshes: Because each service gets a private IP and private DNS out of the box, you can run internal APIs, auth services, and backends that never see the public internet.
• Best for secure internal tools and jobs: Because you can run cron jobs, workers, and ephemeral review apps on Machines that only speak over private networking, you avoid exposing “just-for-us” tools to the world.

Limitations & Considerations

• You still need a public entrypoint somewhere: If users or external systems need to hit your app, at least one Fly service must be exposed via Fly Proxy with an Anycast IP or hostname. Everything behind it, though, can stay private.
• Private networking is Fly-native: Fly’s private network is great for apps running on Fly. If you want to bridge it to your own VPC or data center, you’ll use WireGuard or other integration—powerful, but an extra step.

Pricing & Plans

Fly.io pricing is resource-based: you pay for CPU, RAM, storage, and egress, down to the second for Machines. There’s no separate “private networking” SKU—private networking comes with the platform.

A simple mental model:

• Pay-as-you-go Machines: Best for teams needing flexible, per-service scaling and the ability to spin up ephemeral Machines for jobs or sandboxes without committing to fixed capacity.
• Larger org / enterprise arrangements: Best for teams needing SSO, SOC2 Type 2 attestation, guaranteed support response times, and higher-volume or regulated workloads on a private-by-default platform.

(Concrete pricing changes over time; check the Fly.io pricing page for current numbers.)

Frequently Asked Questions

Can I run multiple services that talk only over private networking, with zero public IPs?

Short Answer: Yes. You can deploy apps on Fly.io that are only reachable on the Fly private network and have no public IPs at all.

Details:
If you don’t define a public service in fly.toml (no [[services]] with internal_port → public ports), Fly Proxy never exposes your app to the public internet. The app still:

• Gets a private IPv6 address per Machine.
• Can reach other apps in your org over the private network.
• Can be reached by other apps using private DNS like my-api.internal.

This is ideal for internal APIs, background workers, databases, or anything you’d normally hide behind a VPN or service mesh. You only assign public IPs to edge-facing apps.

How do services discover and connect to each other privately?

Short Answer: Use Fly internal DNS names or private IPs; traffic stays on the Fly.io private network.

Details:
Every app gets internal DNS resolution and private networking. Common patterns:

• Call another app via <app-name>.internal (for example, users-api.internal:8080).
• Address specific Machines using their private IPs if you want finer control.
• Use built-in private networking docs guidance and, if needed, WireGuard to bridge Fly’s private network to your own infrastructure.

Traffic between these services never exits to the public internet; it rides Fly.io’s private network with end-to-end encryption.

Summary

If you’re looking for a PaaS/container platform that lets services talk over private networking without scattering public IPs everywhere, Fly.io was built for that. Everything runs on Machines on a global private network, you control exactly what’s public via Fly Proxy, and you get sandboxes (Sprites), storage, and routing primitives that behave well with spiky, distributed workloads. You keep the “serverless-like” elasticity and global reach, without inheriting a homegrown Kubernetes and VPN project.

Next Step

Get Started