Publish an HTTP application from your resource

Prepare a virtual machine target

Start your HTTP application on the intended guest port. It must listen on an interface reachable from the private network, not only the guest’s loopback address. Allow the application port through the guest firewall for the intended private path.

Test the application from an authorised private-network client before publishing it. A server running locally inside the VM is not enough if the publishing path cannot reach it.

Prepare a Kubernetes target

Deploy the workload and a Kubernetes Service that selects its pods. Check that the pods are ready and that the Service has endpoints. Use your own namespace and Service name in these inspection commands.

In the publishing form, enter the Service port, which can differ from the container’s targetPort. You do not need to expose the Kubernetes API or create a general public TCP listener.

kubectl --kubeconfig ./my-cluster-kubeconfig.yaml -n my-app get pods
kubectl --kubeconfig ./my-cluster-kubeconfig.yaml -n my-app get service web
kubectl --kubeconfig ./my-cluster-kubeconfig.yaml -n my-app get endpointslices -l kubernetes.io/service-name=web

Create the public route

1. Open Public HTTPS for the machine or cluster in the console.
2. Enter an application name and HTTP port. For a cluster, also enter the Kubernetes namespace and Service name.
3. Choose Publish application and wait for the setup status to become active. Use the generated hostname displayed by the console.
4. Visit the HTTPS address from outside your private network. Verify the expected content and application authentication, not just that some page responds.

Troubleshoot without creating duplicate routes

If setup fails, inspect the existing entry and its message before submitting another request. Check the application port, Service selection and private connectivity. Use Retry HTTPS setup for the existing failed entry after resolving the cause.

An active route does not continuously prove application health. If requests fail, check the workload and target separately from the public routing configuration. Keep the resource or support reference when requesting help.

Withdraw access and clean up

Choose Unpublish for the application and wait until removal is confirmed. Test the old HTTPS address from an external connection before treating public access as withdrawn. Unpublishing the route does not delete the underlying application or its stored data.

If you also delete the VM or cluster, copy anything you need beforehand. Resource deletion removes guest disks or cluster nodes and is not an undoable way to pause a project.