Container management
Inter Service Traffic

Inter Service Traffic

We designate by Inter Service Traffic (IST), the mechanism with which your container services of the same deployment can communicate with each other, in a secure and encrypted way on a TCP level, without any configuration on your side.

How to setup

Suppose you want to communicate 2 services, respectively app and db of the same deployment.

Your app service will automatically have access to a WARP_IST_db environment variable. This variable contains either an IP address or a machine name, which you can use as a host in your app container to contact your db service.

For example, in JS this would result in code like this in your app service:

const { Pool } = require("pg");
const pool = new Pool({
  user: "dbuser",
  host: `${process.env.WARP_IST_db}`,
  database: "mydb",
  password: "secretpassword",
  port: 3211,

Of course, you have to adapt this to your language, and to your situation.

Symmetrically, the db service will have the WARP_IST_app environment variable if it wants to communicate with your app.

These ISTs are secure and encrypted. No other platform service, or any connection from outside, will have access to app and db on the TCP level. These ISTs work of course if your 2 services app and db are on the same runner, but also if they are on two different runners. These ISTs support any port, but are restricted to TCP (no UDP support).

Here (opens in a new tab) an example project that demonstrates communication between two ctna containers calling the ctnb container.

Service visibility

For the moment, in our platform each service has a public url which allows access to the https level. If you want for a service to avoid access on its public url, indicate in the warp.config.jsof the service a port not processed by your service. Access via the public url will be directed to this port, which will do nothing.

To set the port, use deployment.port property.

module.exports = {
  docker: "my-docker-service",
  deployment: {
    port: 65500,