Northflank supports internal networking, public ingress, and VPC ingress. Ingress is incoming traffic to your workloads. Ordinary service ports support HTTP and HTTP/2 on public and VPC ingress, including WebSockets and gRPC over those protocols. Internal ports also support TCP and UDP.
For deployment and combined services, open Configure → Networking in the service menu. For databases and other addons, open Network → Settings in the addon menu.
Public networking
HTTP, HTTP/2, Websockets and gRPC can be exposed publicly via a load-balancer served with an auto-generated TLS certificate with either code.run endpoints or your own domains. HTTPS requests are terminated at the edge load-balancer and the request is then routed internally via Northflank’s network.
You can choose to publicly expose databases and other addons via a load-balanced TCP endpoint. Northflank will enforce and generate TLS certificates which will be automatically configured in the database and connection details.
Northflank will expose your HTTP ports publicly on ports 80 and 443 and route traffic to your configured ports. HTTP (port 80) traffic is automatically redirected to HTTPS (port 443).
On BYOC, public exposure requires the cluster's public ingress to be enabled and ready. Eligible clusters also support VPC ports and dual exposure. VPC ingress needs a private load balancer and client connectivity to the VPC. See Public and VPC ingress for availability.
Supported databases and addons can use VPC exposure instead of public exposure. Addons cannot use both ingress paths simultaneously.
Expose ports in your application
Expose ports in your application to make it available for networking.
Add public ports
Configure ports to expose your services on the internet.
Domains on Northflank
Manage your domains on Northflank, quickly and easily assigning them to your deployments.
Expose a database with TLS
Secure internal database connections or expose it publicly with TLS.
Network security
You can configure security policies for individual ports, or apply path-based access rules consistently across services in a team or organisation. Policies can use IP addresses, request headers, Basic Auth, and SSO to control access.
Apply security policies across services
Protect paths consistently across services in a team or organisation.
Set IP policies
Allow or deny access to services based on IP addresses.
Configure basic authentication
Require users to enter a username and password to access your site.
Use SSO access control
Use your organisation's SSO provider to authenticate access to your services.
Configure security policies by path
Set security policies to restrict access to your endpoints based on port and subdomain path.
Private networking
Ports serving all supported protocols can use project-internal networking. Internal addresses allow access from resources in the same project by default. This differs from VPC ingress, which exposes selected workloads through a private load balancer.
Deployments and databases can be forwarded for secure, local access, without the need to publicly expose them to the internet.
You can enable multi-project networking to securely access resources from another Northflank project, and enable Tailscale in your projects to access resources in your Tailscale VPN.
Add private ports
Configure ports to allow your services to communicate securely within your project.
Forward deployments and databases
Forward deployments and databases to your local machine for development.
Multi-project networking
Configure projects to securely allow ingress network traffic from other projects.
Use Tailscale
Allow secure access to Tailscale devices to resources within your project.
Load-balancing strategies
Northflank uses scalable and highly performant load balancers to securely distribute external traffic to services in your projects.
When you create a service you can select the load-balancing strategy to use, the default selects the instance with the least current traffic.
Headers
For public HTTP/S requests, Northflank sets X-Envoy-External-Address to the IP address of the connecting client. It replaces any value sent by the client. If a CDN or another proxy sits in front of Northflank, the header identifies that proxy.
For internal or VPC requests, do not assume this header exists or that Northflank replaces values sent by the client.
The X-Forwarded-For header contains a comma-separated list of addresses supplied by clients and proxies. For requests through Northflank's ingress, Northflank preserves existing entries and appends the connecting client's IP to the end. Do not assume that all entries in X-Forwarded-For are trustworthy.
Request and response headers can also be managed by configuring path-based routing for your subdomains.