Port-forwarding allows you to access your application on
localhost:[PORT] by forwarding the network traffic from a localhost port to a specified port of a container.
When starting the development mode, DevSpace starts port-forwarding as configured in the
dev.ports section of the
Unique Local Port
port option must be unique across your entire
ports section, e.g. you can only use the value
8080 once for the
port option in your
Every port-forwarding configuration consists of two parts:
name option is optional and expects a string stating the name of this 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 to which the traffic should be forwarded:
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 port-forwarding connection to the selected pod or loses it after starting the port-forwarding, DevSpace will try to restart 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
imageNameoption of the first port-forwarding configuration in the
backend. That means DevSpace would select the first container for port-forwarding, as this container uses the
image: john/devbackendwhich belongs to the
backendimage as defined in the
imageNameoption of the second port-forwarding configuration in the
backend-debugger. That means DevSpace would select the second container for port-forwarding, as this container uses the
image: john/debuggerwhich belongs to the
backend-debuggerimage as defined in the
In consequence, the following port-forwarding processes would be started when using the above config example:
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.
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.
forward section defines which localhost
port should be forwarded to the
remotePort of the selected container.
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.