Skip to main content
Networking decides who can reach an application and how. Public networking covers traffic from the internet: HTTP traffic to the web process, IP restrictions, TCP proxies for other protocols, and the egress IP addresses the application’s outbound traffic comes from. Private networking covers traffic between your services in the same location: internal hostnames, internal connections and private ports. All of it lives on the application’s Networking tab; CDN and edge caching have their own page.

​
How traffic reaches your application

A visitor's request passes through Cloudflare's edge and Sevalla's edge worker, which applies IP restrictions, the HTTPS redirect and maintenance mode, and answers from the edge cache when it can. The rest goes to the load balancer and ingress in your application's location, which routes it by domain to an instance of the web process, and instances reach the database in the same cluster over an internal connection. A visitor's request passes through Cloudflare's edge and Sevalla's edge worker, which applies IP restrictions, the HTTPS redirect and maintenance mode, and answers from the edge cache when it can. The rest goes to the load balancer and ingress in your application's location, which routes it by domain to an instance of the web process, and instances reach the database in the same cluster over an internal connection.
  1. A visitor opens one of the application’s domains on port 443. Cloudflare answers, redirects plain HTTP (port 80) to HTTPS with a 301, and applies IP restrictions, maintenance mode and caching.
  2. Cloudflare forwards the request to the application’s location, where Sevalla routes it to an instance of the web process on the web process port, 8080 by default. The request carries the headers Cloudflare and Sevalla add.
  3. Non-HTTP clients connect through a TCP proxy instead, and your other services use internal hostnames on the private network.
While the web process uses the H1 size, the application can’t have custom domains and answers only on its sevalla.app domain. See Instance sizes.

​
Web process port

The web process port is the port your web server listens on inside its container. Every domain of the application routes to it. It’s 8080 by default, and Sevalla sets the PORT environment variable to it, so the safest setup is a server that listens on PORT:
server.js
Listen on 0.0.0.0 (all interfaces), not localhost or 127.0.0.1, or requests can’t reach the server.
1

Open the Networking tab

In the sidebar, click Applications, then click the application. Click the Networking tab.
2

Update the port

In Expose HTTP traffic, click Update port, enter the Port your web process listens on, and click Update port.
The port must be a whole number from 1 to 65535. Ports 15000, 15001, 15004, 15006, 15008, 15009, 15020, 15021, 15053 and 15090 are reserved for the platform. The dashboard accepts them, but Sevalla then runs the web process on 8080 instead, so pick another port. Sevalla applies the change to the running web process without a new deployment, and the domains in the section show the new port, for example http://0.0.0.0:3000.
The Expose HTTP traffic section listing the application's domains on port 8080, above the CDN and edge caching sectionThe Expose HTTP traffic section listing the application's domains on port 8080, above the CDN and edge caching section

​
Use gRPC

The web process speaks HTTP by default. To serve gRPC, click Update protocol in Expose HTTP traffic, pick gRPC in Protocol, and click Update protocol. Your web process must then serve cleartext HTTP/2 (h2c) on its port; Cloudflare and Sevalla handle TLS. The section’s title changes to Expose gRPC traffic. Switch back the same way.

​
Turn HTTP traffic off

Turn HTTP traffic off to make an application private: its web process stops receiving requests and its domains stop answering, while every process keeps running. Use it for an API that only your other services call over an internal connection.
1

Disable HTTP traffic

In Expose HTTP traffic, click Disable.
2

Confirm

In the Disable HTTP traffic dialog, click Disable HTTP.
The domains then show HTTP is disabled. To turn traffic back on, click Enable, then Expose HTTP. Hibernation has no effect while HTTP traffic is off.

​
IP restrictions

IP restrictions allow or block HTTP traffic by the visitor’s IP address. Cloudflare checks every request to every domain of the application before anything else, and a blocked request gets a 403 with the body Forbidden. Each entry is an IPv4 or IPv6 address (203.0.113.7) or a CIDR block (203.0.113.0/24). There’s no limit on the number of entries. Only one mode is active at a time.
1

Open IP restrictions

On the application’s Networking tab, click Update IP restrictions.
2

Pick a mode and the addresses

Choose IP allowlist or IP denylist. Enter an address or CIDR block, and click Add IP address for each one more.
3

Save

Click Update IP restrictions.
The Update IP restrictions sheet with the No IP restrictions, IP allowlist and IP denylist options and a list of addressesThe Update IP restrictions sheet with the No IP restrictions, IP allowlist and IP denylist options and a list of addresses
The section then reads IP allowlist active or IP denylist active, with the list. Cloudflare locations can take up to a minute to apply a change. Invalid entries show Invalid IP address or CIDR, and repeated ones This address is already in the list. IP restrictions apply to HTTP traffic on the application’s domains. They don’t apply to TCP proxies or to the private network.
With an allowlist active, every address not on it gets a 403, including yours. Add your own address first.

​
TCP proxies

A TCP proxy gives a process a public hostname and port for traffic that isn’t HTTP, such as a database you run yourself, a message broker, or a WebSocket server running as a background worker. Connections to the proxy’s hostname and port are forwarded to the port the process listens on.
1

Open the form

On the application’s Networking tab, click Create TCP proxy.
2

Pick the process and port

Pick the Process, enter the Port it listens on (default 8000), and click Create TCP proxy.
The proxy shows Creating TCP proxy, then TCP proxy is enabled with its address (for example storefront-x7k2m-a1b2c.ext.sevalla.app:24817) next to the process port. Sevalla applies it to the running process without a new deployment. Connect your clients to that address.
The Create TCP proxy sheet with a Process picker and a Port field set to 8000The Create TCP proxy sheet with a Process picker and a Port field set to 8000
Every TCP proxy is also a private port: the port stays reachable on the private network, marked Also public. To remove the public endpoint, click ⋯ on the proxy, then Delete, and confirm with Delete TCP proxy. Its hostname and port stop working, and the port stays in Private ports.

​
Legacy TCP proxy endpoints

TCP proxies created before the current endpoints used a hostname of the form <cluster>.proxy.sevalla.app and a port from 30000 to 30999. Those legacy hostnames and ports were disabled on Oct 15, 2026, and connections to them fail. If the dashboard shows Your TCP proxy endpoint has changed (or endpoints have changed), update your clients to the address listed for each proxy; Show legacy endpoints lists the old ones for reference. See Legacy TCP proxy and external connection endpoints.

​
Egress IP addresses

Egress IP addresses are the public addresses that the application’s outbound connections come from, for example to an external database, a payment API or a mail provider. If the service you connect to restricts access by IP, allowlist these addresses there. The Egress IP addresses section of the Networking tab lists them, and what you get depends on the location:
Egress addresses are shared with other workloads in the same location, so an allowlist entry doesn’t identify your application alone. Where the external service supports it, also authenticate with credentials such as an API key or a username and password.
Outbound connections to the SMTP ports 25, 465 and 587 are blocked in every location, and port 2525 too in Oracle Cloud locations, because Sevalla doesn’t host email. Send email through your email provider’s HTTP API, or through another SMTP port your provider offers. See Outbound traffic.

​
Oracle Cloud egress IP addresses

When an application moves to Oracle Cloud Infrastructure, its egress address changes to the one of its new location. Update IP-based allowlists before the move.

​
Internal hostnames

Every web process and background worker has an internal hostname that your other services use to reach it on the private network, without leaving the data center. It has the form <application name>-<process key>.<application name>.svc.cluster.local; the web process’s key is web, for example storefront-x7k2m-web.storefront-x7k2m.svc.cluster.local. The Internal hostnames section lists each process’s hostname with a copy button. Another service reaches the hostname only through an internal connection, on the web process port or a private port. Cron jobs and jobs have no internal hostname.

​
Internal connections

An internal connection opens the private network between this application and a database or another application in the same location. Traffic over it stays inside the data center and doesn’t pass through Cloudflare. Use it instead of a database’s external connection whenever both services run on Sevalla.
Both services must be in the same location, and you need permission to update both. To connect services in different locations, clone the application into the database’s location.
1

Open the form

On the application’s Networking tab, in Connected services, click Add internal connection.
2

Pick the service

In Service, pick an application or database. The list shows the services in the same location that aren’t suspended or connected yet.
3

Add the variables

Turn on Add environment variables to the application to save the service’s host, port and credentials as environment variables. Rename the keys if your framework expects other names, and choose Available during runtime and Available during build.
4

Connect and deploy

Click Add internal connection, then deploy the application so it gets the new variables.
The Add internal connection sheet with a Service picker and the Add environment variables to the application switchThe Add internal connection sheet with a Service picker and the Add environment variables to the application switch
The service appears in Connected services with its internal hostname and port (a database) or its processes’ hostnames (an application). You can also add the connection from the database’s side; see Connect to a database. To remove a connection, click ⋯ on it in Connected services, then Delete, and confirm with Delete connection. The application can no longer reach the service. The variables added with the connection stay; delete them on the Environment variables tab if you don’t need them.

​
Private ports

A private port exposes another port of a web process or background worker on the private network, for example a metrics endpoint or a gRPC port next to the HTTP one. Connected services reach it on the process’s internal hostname.
1

Open the form

On the application’s Networking tab, in Private ports, click Expose private port.
2

Pick the process and port

Pick the Process, enter the Port it listens on, and click Expose port.
The port appears in Private ports, and Sevalla applies it to the running process without a new deployment. A process can have up to 100 private ports by default. To remove one, click ⋯, then Delete, and confirm with Delete port. If the port also has a TCP proxy (Also public), deleting the port deletes the proxy and its public address too.

​
API and CLI