Reverse port-forwarding allows you to forward traffic from within your containers to your local machine. This can be useful when:
- using certain remote debuggers that connect to your IDE instead of the other way around
- developing a service on localhost which should be accessed from other services that run within the cluster, i.e. using the Telepresence development model but with DevSpace to get better performance and cross-platform support
With reverse port-forwarding, you can access
localhost:[PORT] inside the container and it will redirect to a program that runs on your local dev machine.
When starting the development mode, DevSpace starts reverse port-forwarding as configured in the
dev.ports section of the
Unique Remote Port
remotePort option must be unique across your entire
ports section for all selectors that match the same pods, e.g. you can only use the value
8080 once for the
remotePort option in your
ports section unless multiple port mappings target different pods.
Every reverse port-forwarding configuration consists of two parts:
name option is optional and expects a string stating the name of this reverse port-forwarding configuration. This can be used as a steady identifier when using profile patches or to override the log message prefix for this port configuration.
The following config options are needed to determine the pod from which the traffic should be forwarded to localhost:
If you specify multiple of these config options, they will be jointly used to select the pod / container (think logical
AND / &&).
If DevSpace is unable to establish a reverse port-forwarding connection to the selected pod or loses it after starting the reverse port-forwarding, DevSpace will try to restart reverse port-forwarding several times.
imageSelector option expects a string that specifies an image (e.g.
my-registry.com/lib/my-image:tag) to select a target pod and container with. The newest running pod that has a container which matches this image will be selected by DevSpace.
In addition, you can also reference images from the
images section in the
- If the image in
images.*.image, DevSpace will automatically append the latest built tag during runtime to the
- You can also let DevSpace resolve the target image and tag by using runtime variables
- The above example defines two images that can be used as
- The deployment starts two containers and each of them uses an image from the
imageSelectoroption of the first reverse port-forwarding configuration in the
backend. That means DevSpace would select the first container for reverse port-forwarding, as this container uses the
image: john/devbackendwhich belongs to the
backendimage as defined in the
imageSelectoroption of the second reverse port-forwarding configuration in the
backend-debugger. That means DevSpace would select the second container for reverse port-forwarding, as this container uses the
image: john/debuggerwhich belongs to the
backend-debuggerimage as defined in the
In consequence, the following reverse port-forwarding processes would be started when using the above config example:
localhost:80inside the container will forward to
localhost:8080on your local machine
localhost:3000inside the container will forward to
localhost:3000on your local machine
labelSelector option expects a key-value map of strings with Kubernetes labels. This can be used to select the correct target pod with labels instead of the image name like
imageName. If the pod you want to select has multiple containers, make sure to use
containerName as well.
labelSelectorwould select the pod created for the component deployment
- Because containers in the same pod share the same network stack, we do not need to specify which container should be selected.
containerName option expects a string with the name of the container to use within the pod selected by
labelSelector. This option is not required if
imageName is used or there is only one container inside the selected pod.
namespace option expects a string with a Kubernetes namespace used to select the pod from.
It is generally not needed (nor recommended) to specify the
namespace option because, by default, DevSpace uses the default namespace of your current kube-context which is usually the one that has been used to deploy your containers to.
reverseForward section defines which
remotePort inside the selected container should be forwarded to the
port on your local machine.
remotePort will take the same value as
remotePort is not explicitly defined.
port option is mandatory and expects an integer from the range of user ports [1024 - 49151].
port < 1024 is likely to cause problems as these ports are reserved as system ports.
remotePort option expects an integer from the range of valid ports [0 - 65535].
remotePort has the same value as
remotePort is not explictly defined.
bindAddress option expects a valid IP address that the local port should be bound to.
Default Value For
Arch specifies which DevSpace helper architecture should be used for the container. Currently valid values are either no value,
arm64. Depending on this value, DevSpace will inject the DevSpace helper binary with the corresponding architecture suffix.