No https URL generated on AKS?

I recommend that you get more familiar with Okteto Self-Hosted before you proceed. Okteto Self-Hosted is not your application. At a very high level, Okteto Self-Hosted is just like Okteto Cloud, but instead of running in Okteto’s clusters, it runs on your Kubernetes cluster. I’m not sure what you are trying to accomplish, but Okteto Self-Hosted doesn’t sound like the best alternative for your use case.

I understand instead of hosting on, it is hosting internally with AKS but using okteto CLI

This typically means that you didn’t create a DNS entry for your Okteto Self-Hosted instance. Azure Kubernetes Service (AKS) | Okteto Documentation has the instructions for AKS. Please open another thread if you have questions about this, so it’s easier to follow it.

You’ll need to fix this before being able to use your Okteto Self-Hosted instance.

When using Okteto Self-hosted, think of Okteto Self-Hosted as becoming a proxy for accessing your Kubernetes cluster. When you run okteto deploy, what happens is something like: okteto deployokteto self-hosted API kubernetes API (it’s more complicated than that, but I’m over-simplifying). This allows Okteto to create HTTPS endpoints automatically, being compatible with Docker-Compose or build your containers remotely in the cluster.

To be able to access the okteto self-hosted API, you need to authenticate first. This is what okteto context use https://okteto.$SUBDOMAIN does. That’s why you need to pass the URL to your Okteto Self-Hosted instance (so it knows where to find the API) instead of the name of your Kubernetes cluster.

Yes but $DOMAIN is not yet created? Is that the correct assumption. It seems to me we need to authenticate to a $DOMAIN to define the context but $DOMAIN is not there ? if $DOMAIN was created could you let me know when or which command created it? Or it does not need to pre-exist?


Now getting:

Couldn’t authenticate to okteto cluster: authentication timeout
Try to set the context using the ‘token’ flag: Okteto CLI | Okteto Documentation

So okteto context is not selecting which AKS cluster to work in? I would have thought it was hence showing one of few clusters available to select

okteto.$SUBDOMAIN is not dynamic. This is the URL of your Okteto Self-Hosted instance. You should replace $SUBDOMAIN with the domain you are using.

In my Okteto Self-Hosted instance, the value of $DOMAIN is I run okteto context use to authenticate.

You have to create DNS entries as part of installing Okteto Self-Hosted. Azure Kubernetes Service (AKS) | Okteto Documentation has instructions on how to do this.

Could you comment out the actual name as it is not public yet thanks, I will take screen shot

Yes I already created the DNS entries

If you are having DNS resolution issues, please post a separate question. It’s easier to give you help that way. As part of the question, please paste the output of nslookup (replacing with the domain you used when creating the DNS entries).

Used Personal Access Token generated:

This site can’t be reached

nslookup okteto.$SUBDOMAIN
Server: 192.XXX.XX.X
Address: 192.XXX.XX.X #53

** server can’t find okteto.$SUBDOMAIN: NXDOMAIN

Could this be that DOMAIN already exists outside of Azure AKS, but trying to create a SUBDOMAIN out of an existing DOMAIN that is not controlled by the same Azure AKS?

Does this show it is resolved:


Yes, that looks correct. What happens when you browse to https://okteto.$SUBDOMAIN?

Fails, can’t be reached. Or we need to follow Bring your own Cert section?

Hi @ramiro after working with host provider nslookup to add subdomain resolves it to a public IP address created in Azure

Server: 192.168.XX.1
Address: 192.168.XX.1#53

Non-authoritative answer:
Address: 20.XX.XX.XXX

But ok context → Create new context → --token —token Authentication will continue in your default browser
You can also open a browser and navigate to the following address:

Then “This site can’t be reached”

Is the reason this fail to do with subdomain created by host provider does not have the SSL etc certificate?

Does nslookup need to resolve


as well as with SSL?

A "This site can’t be reached” error normally means that your DNS is not configured correctly. Is the IP that nslookup resolves accessible from the network that you are using?