Introducing Restricted Ports

At its core, CloudCaptain analyses the payload you pass it (like a .jar or .war file) and generates a minimal immutable image for it. This image contains two main parts: a disk image and metadata.

The metadata is what interests us here. It is built as part of the analysis phase and contains information about your app, such as the ports and the healthcheck urls it requires. If you use Spring Boot or Dropwizard this info can even be automatically extracted for you from these frameworks' native configuration files.

CloudCaptain then later uses this metadata when running instances of your images to correctly provision infrastructure. In the case of AWS, CloudCaptain will use the port and healthcheck info to automatically set up and configure Elastic Load Balancers, Security Groups and more.

However so far, unless you explicitly configured a custom security group, any port you have opened was always open to the world:

Unrestricted ports

While this is great for publicly facing parts of the service like http(s) ports it may not always be what you want for other parts of it like the admin interface for example.

Restricted Ports

Today we are introducing a new CloudCaptain feature called Restricted Ports. What this allows you, is to further constrain the access rights of a specific port down to a specific range of ip addresses.

We have added support for fixed addresses like as well as CIDR blocks such as (granting access to all ip addresses between and

Additionally we have also added support for a special address denoted by @, which refers to the current public ip of your local workstation. This is particularly useful when working with protocols which lack authentication such as JVMTI for debugging. You can now open a debug port that is only accessible from your own IP address.

If your ISP assigns you dynamic addresses you can combine these approaches and grant access to the CIDR block of your current IP such as @/22.

This is how this then works out in practice if you want to for example restrict the access of the admin port of your app to the current ip of your workstation:

Ports restricted to your workstation

UDP Ports

Another feature we added is support for UDP as not every service needs the additional features (and overhead) of TCP. To achieve this you can simply add /udp to the port definition:

> boxfuse run -ports.myudpsrvc=6543/udp

This will then effectively expose UDP port 6543 to the world. This is of course combinable with the restricted ports described above.


While certain protocols or interfaces aren't meant to be publicly available, yet are an important part of your application, we have introduced Restricted Ports to make it easy to constrain access to a single address or a CIDR block. We have also added support for the convenience value @ to easily refer to the current public ip address of your workstation. On top of that it is now possible to also open UDP ports.

Here is for reference the complete list of currently supported syntax variants for port definition:

80TCP port 80, universally accessible
80/tcpTCP port 80, universally accessible
80/udpUDP port 80, universally accessible
80/tcp:@TCP port 80 only accessible from your own IP
80/udp:@/20UDP port 80 only accessible from the IPs in the CIDR /20 block of your own IP
80/udp: port 80 only accessible from
80/tcp: port 80 only accessible from the IPs in the CIDR /31 block of

Have fun and keep on deploying JVM applications to AWS with ease and pleasure!

And if you haven't already, sign up for your CloudCaptain account now. All you need is a GitHub user and you'll be up and running in no time. The CloudCaptain free plan aligns perfectly with the AWS free tier, so you can deploy your JVM application to EC2 completely free.

« Expanding fast AMI creation to us-east-1 and eu-west-1
It's Auto-Scaling time! »