Networking

Networking is how applications can communicate with other applications or databases. There are two main ways this can be achieved:

• Public networking: Connections that are accessible from the Internet or external networks. This makes an Internet round-trip, so it can be slower than private networking. With Kinsta’s Application Hosting, you can connect to your application publicly using a specific port or TCP proxy.
• Private networking: Connections that stay within our network and are not directly accessible from the Internet. We strongly recommend this method if you’re connecting applications hosted on Kinsta or linking an application with a database also hosted on Kinsta. To use Kinsta’s private network, all applications and databases must use the same data center.

You can configure your application’s public or private port, disable HTTP(S) traffic, or add an internal connection within Applications > app name > Networking.

Public networking

Edit protocol

Use this to switch the web process protocol between HTTP and gRPC. gRPC is a protocol that allows browser-based applications to connect with gRPC services over HTTP so different parts of an application, or even different applications, can communicate with each other efficiently over a network.

Edit application port

By default, the port for your application’s web process is 8080. When an application is deployed, it is reachable on the internet on ports 80 and 443, and we route those ports to the container on the port defined by your application. This port is available during application runtime on the $PORT environment variable. You can define a different port; however, it must be within the range 1-65535 except for the following ports used by our core system: 15000, 15001, 15004, 15006, 15008, 15009, 15020, 15021, 15053, and 15090.

To configure a specific port for your application, click Edit port, enter the new port, and click Update. 

Disable HTTP(S) traffic

To disable all HTTP(S) traffic for your web process, click Disable > Disable.

CDN/Edge caching

A content delivery network (CDN) is crucial for modern hosting, and Kinsta provides a premium Cloudflare-powered CDN at no extra cost. Our free Cloudflare integration enhances security with an enterprise-level firewall, DDoS protection, and a high-performance HTTP/3 CDN. With a network spanning 260+ cities in over 100 countries, Cloudflare ensures fast delivery of your static assets from global locations without additional charges.

Edge caching stores your Kinsta site/page cache across Cloudflare’s global network, delivering cached responses from the nearest data center to your visitors, boosting performance and speed. However, static assets like images, CSS, and JavaScript files are handled separately by Kinsta’s CDN.

Enable CDN/Edge caching

To enable the CDN or edge caching, click Edit settings.

To enable the CDN, select CDN status, and to enable edge caching, select Edge caching status.

Clear cache

To clear the CDN or edge cache, within CDN/Edge caching, click Purge cache. If both CDN and edge caching are enabled, purging the cache will apply to both.

Clearing edge cache in all of Cloudflare’s data centers may take 2-5 minutes to fully complete.

TCP proxy

You can connect to any of your processes over TCP using a proxied domain and port. This allows you to expose non-HTTP traffic, simplifying the deployment of services like MongoDB or RabbitMQ with public access. You can also use it to deploy a Laravel app with Reverb (a WebSocket server) as a single application, with Reverb running as a background worker while still being publicly accessible.

To set up a TCP proxy, click Add TCP proxy.

Choose the Process you want to connect to via TCP proxy, enter the Port you want to use, and click Add TCP proxy.

Once the TCP proxy is added, a hostname is assigned to the process, which you can use to connect to it.

Private networking

This shows the hostname for all of the application processes. You can use the hostname to connect to the processes on Kinsta’s private network.

Ports

You can expose a port internally to improve communication between applications. This is especially useful in microservice architectures or when running services like RabbitMQ or databases that require internal network accessibility.

To expose a port internally, click Expose port, choose the Process you want to expose the port for, enter the Port, and click Expose port.

Kinsta automatically deploys your application when you expose a port.

Connected services

This shows any applications or databases that are connected to the current application over Kinsta’s private network.

Add a private connection

You can add a private connection from an application’s Networking page or a database’s Overview page. Wherever you start the process, the result will be the same.

To add a connection from an application to another application or database, go to Applications > app name > Networking > in the Connected services section, click Add connection, and select the application or database you’d like to create the internal connection to.

Environment variables

We can automatically populate an application’s environment variables from the connection details. Do not copy and paste the internal connection details into environment variables. Click Add connection or Add application and select the Add environment variables… checkbox. This will automatically populate the environment variables from the application or database you’re connecting to.

Some applications may expect environment variables (keys) with different names. You can edit the names in the list before adding the connection or edit them later on the application’s Environment variables page.

Private connections and the build process

Private connections are only available during runtime; they are not available during the build process.

If your application tries to connect to a database using an internal connection during the build process, this causes an error that says the database is not running, which makes the build fail. This is expected because the internal connection is not live during the build; it can only be used during runtime.

There are a couple of ways to work around this.

Option 1: Move the logic that connects to the database from the application’s build command to the start command. For example: if you have a command like prisma migrate in the build process and move that command to the start command, your application will only access the database during runtime, and the build will be successful.

Option 2: Add separate environment variables as needed for the database connection, one available for the build process, and the other only for runtime. The keys can be the same (e.g. DB_CONNECTION_URL) as long as one is only available during the build process and the other is only available during runtime. Use the database’s External connection details (Databases > dbname > Overview > External connections) for the values of any variables to be used in the build process.

Remove a private connection

If you need to remove a connection, go to the Application’s Networking page, and under Connected services, click the delete (trash can) icon.

In the Delete connection modal/pop-up, click Delete connection to confirm and remove the connection to the application.