Skip to main content
Version: 0.3


Applications will need to be reachable by their users. This can be users on the internet, within the organization, and other application teams. When deploying the Acorn app, there is a lot of flexibility.


By default Acorn apps run with the Acornfile author's default configurations.

acorn run

Publish all ports

To publish all ports you can run with -P or the long form --publish-all.

Publish no ports

To launch the Acorn app with all ports internal, you can launch with the -P=false or --publish-all=false.

Publish individual ports

Publishing ports makes the services available outside of the cluster. HTTP ports will be exposed via the layer 7 ingress and TCP/UDP ports will be exposed via service load balancers.

Flag valueDescription
-p 80Publish port 80/tcp in the Acorn to port 80/tcp as a service load balancer.
-p 80/httpPublish port 80/http in the Acorn to a random hostname.
-p 81:80Publish 80/tcp in the Acorn to 81/tcp as a service load balancer.
-p 81:80/tcpEquivalent to -p 81:80.
-p app:80Publish container app port 80/tcp in the Acorn to 80/tcp as a service load balancer.
-p app:80/tcpEquivalent to -p app:80.
-p container app protocol HTTP from the Acorn to external name
-p container app port 80 from the Acorn to external name
-p app:80Publish container app port 80 from the Acorn.

Expose individual ports

Exposing ports makes the services available to applications and other Acorns running on the cluster.

Flag valueDescription
--expose 80Expose port 80/tcp in the Acorn to port 80/tcp as a cluster service.
--expose 81:80Expose 80/tcp in the Acorn to 81/tcp as a cluster service.
--expose 81:80/tcpEquivalent to --expose 81:80.
--expose 81:80/httpExpose 80/http in the Acorn to 81 as a cluster service.
--expose app:80Expose container app port 80/tcp in the Acorn to 80/tcp as a cluster service.
--expose app:80/tcpEquivalent to --expose app:80.
--expose web:80:app:80Expose container app port 80/tcp as cluster service called web on port 80/tcp.


When an Acorn app has published a port, it will be accessible on a unique endpoint. This endpoint can be seen in the output of acorn app:

NAME             IMAGE                 HEALTHY   UP-TO-DATE   CREATED     ENDPOINTS                                                                           MESSAGE
purple-water my-org/my-acorn:v1 2 2 50s ago => default:8080 OK

You have significant control over the domain name in your endpoints, as described below.

Cluster Domain

Your cluster domain is the domain used as the suffix for all your Acorn apps' endpoints.

If you're running a local cluster, such as Docker Desktop, Rancher Desktop, or Minikube, the cluster domain will be and will always resolve to localhost.

If you are running any other type of cluster, Acorn provides a DNS service that will reserve a unique cluster domain and create publicly accessible DNS entries for you. The domain will look like <random cluster ID> and will resolve to the hostnames or IP addresses supplied by your ingress controller. This domain is unique to your cluster and will be used for all Acorn apps.


The DNS service is a public service ran on the Internet. Your Acorn installation must have outbound access to to access it.

To create and maintain public DNS entries, the DNS service expects your Acorn installation to make on-demand and periodic renewal requests to it.

If your Acorn installation ceases to make requests to the DNS service, your DNS entries and reserved domain will eventually expire and be deleted.

You can choose to use your own cluster domain instead of the generated domain like so:

acorn install --cluster-domain

If you do so, you must manage your own DNS entries.

You can turn off the Acorn DNS feature as part of installation (or after by rerunning the command):

acorn install --acorn-dns disabled

This will prevent Acorn from reserving a domain for your cluster. If you disable the DNS service and haven't defined a custom cluster domain, the domain will be used as a fallback.

Naming Conventions

The endpoints generated for your Acorn apps follow this convention:

<container name>.<app name>.<namespace>.<cluster domain>

Here's an example:

Let's break that FQDN down:

  • web is the name of the container from your Acorn app. If the container name is "default", it will be omitted from the FQDN.
  • purple-water is the generated name of your Acorn app. You can control this by supplying a name through the --name flag.
  • my-namespace is the namespace you deployed your Acorn app into. By default, we use the acorn namespace. If you are using this default, it is omitted from the FQDN.
  • is the cluster domain generated for your cluster. You can control this as described in the previous section.

To highlight the level of control this gives you, consider the following:

If you set your cluster domain to, deployed into the default acorn namespace, named your app blog, and the container name in the Acornfile was default, the published endpoint for your app would be:

In addition to this method of controlling your endpoint, you can publish to an explicit external name using the --publish flag. See the publishing ports section for more details.