Private networking

Services in the same project and environment can reach each other over a private network, without a public domain and without leaving the cluster. To connect services of different projects, put their environments in a private network (VPC).

Private hostnames

Every service has a private hostname:

<service>.<environment>.internal

For example, a service called api in production is reachable at api.production.internal. The hostname is shown in Settings → Networking and available to the service itself as FJORDRUN_PRIVATE_DOMAIN.

Connect on the port the target listens on, over plain HTTP or the database's own protocol:

API_URL=http://api.production.internal:8080
DATABASE_URL=postgresql://postgres:<password>@postgres.production.internal:5432/fjordrun

Rather than hard-coding hostnames, reference the other service's variables:

API_URL=http://${{api.FJORDRUN_PRIVATE_DOMAIN}}:8080
DATABASE_URL=${{Postgres.DATABASE_URL}}

Project-qualified hostnames

Every service also has a hostname that names its project:

<service>.<environment>.<project>-<project id>.internal

For example api.production.billing-3f9a12bc.internal, where 3f9a12bc is the start of the project's ID. Use it to reach a service in another project of the same private network. It is shown in Settings → Networking and available as FJORDRUN_QUALIFIED_PRIVATE_DOMAIN.

Only the project ID part is used to find the service; the name part is there to make it readable. If you rename the project, the new hostname is shown, and the old one keeps working.

What can talk to what

Network policies inside your team's namespace allow traffic:

• between services of the same project and environment;
• from the Fjordrun ingress (for public domains) and from the platform's monitoring;
• from the Fjordrun TCP proxy, only to ports you turned public TCP on for;
• out to the internet, except private address ranges and the cloud metadata endpoint.

Everything else is denied: staging cannot reach production, one project cannot reach another, and other teams cannot reach your services at all. A private network is how you open a path between projects of your team.

Private networks (VPCs)

A private network groups environments of several projects in your team. Every service in one of its environments can reach every service in the others, at their project-qualified hostnames. Environments that are not in a private network stay isolated, as before.

Typical uses: a shared database project used by several apps, or a backend split into projects that are deployed separately.

Create one

1. Open Team settings → Private networks and create a network, for example backend.
2. Add the project environments that should talk to each other, for example Shop · production and Billing · production.
3. Point your services at each other with the project-qualified hostname, for example http://api.production.billing-3f9a12bc.internal:8080.

Changes apply within seconds. Running services are not restarted.

Rules:

• An environment can be in one private network at a time. Remove it from one before adding it to another.
• Only environments of your own team can be added. Teams never share a network.
• Team owners and admins create, rename and delete networks and change their members. Every member of the team can see them. A project-scoped API token only sees the networks its project is in, and cannot change them.
• Adding or removing an environment, and creating, renaming or deleting a network, is recorded in the team's activity.
• Production and staging of the same project can be in the same network, but usually should not be.

Variables across projects

Inside a private network, a service can reference the variables of a service in another member project with ${{<project>.<service>.<VARIABLE>}}:

BILLING_URL=http://${{Billing.api.FJORDRUN_QUALIFIED_PRIVATE_DOMAIN}}:8080
BILLING_DATABASE_URL=${{Billing.Postgres.DATABASE_URL}}

The project is matched by name, ignoring case. A reference resolves to an empty value when the project is not in the same private network, when two member projects have the same name, or when a service of your own environment has the same name as the project. Seen through such a reference, the other service's FJORDRUN_PRIVATE_DOMAIN is its project-qualified hostname, so values built from it, like the database templates' DATABASE_URL, work from your project. Hostnames typed out in a variable are not changed: use the project-qualified one there. Values are resolved at deploy time: redeploy to pick up a change in the other project.

Putting environments in the same network lets their services read each other's variables this way. Only add environments whose services you trust with each other's secrets.

Locations and latency

A private network can include environments of projects in different locations of the same cluster. Traffic between them stays on Fjordrun's private network and is never billed, but it crosses the distance between data centers: a few milliseconds between Nuremberg and Falkenstein, and more to Helsinki, compared with well under a millisecond inside one location. Keep chatty services, such as an app and its database, in the same location. During the beta every project runs in Nuremberg (see Regions).

Plans

	Trial	Hobby	Pro
Private networks per team	–	2	10
Environments per network	–	6	30

Private networks have no price of their own, and traffic inside them is not counted as egress.

API

Private networks are managed under /teams/{tid}/vpcs: list, create, rename, delete, and add or remove member environments (tag Private networks in the API reference).

Keep internal services private

A service only gets a public URL when you add a domain to it. Databases and internal APIs need no domain; leave them private. Ollama, for example, has no authentication and should never get a public domain.