How can I configure astro/airflow to use a custom IP, not localhost?


I am trying to set up the Astro CLI on our shared dev server. I succeeded in installing and starting (astro airflow start). By default, the Airflow Webserver is hosted at http://localhost:8080/admin/. I need to configure that so that it is accessible from my local machine. Is there a way to specify the IP or network interface that the webserver is bound to?


In your project directory, you should be able to run astro airflow init to scaffold out a project, if you haven’t yet. Once you have those files created, you can edit the config file at ./.astro/config.yaml and add:

  port: 8081

to switch the webserver port to 8081, for instance.


We don’t need to change the port we need to change the host. Ie, the webserver is hosted at http://localhost:8080/admin/ but I need access to it remotely so I need host to be, I think. I’ve tried putting


In my config.yaml but that didn’t work. Also tried hostname instead of host.


Ah, my fault. A few of us were talking and somehow I thought we were only dealing with the port.

Under the hood the CLI is using docker-compose type functionality through a library called libcompose. After some googling, it looks like docker-compose supports passing an IP through when you bind the port. I found this explaination -

If libcompose works the same way you might be able to change your port setting to be something like:


For reference, that part of the CLI is here:


Unfortunately, that doesn’t work. That produces Airflow Webserver: http://localhost:


Ah, yea it looks like the CLI prints out a malformed URL because we have the localhost part hard coded. We haven’t really considered this use yet, but we can patch that up.

Even though the output link is wrong, I was able to test this out here on our local network. I used the above config, and was able to access the webserver UI locally, as well as from another machine on the network.


You’re right. That does actually work. We were having unrelated issues connecting to our dev box that masked the fact that we fixed this configuration. Thank you very much for your guidance and independent testing. Patch on the stated webserver URL would be awesome.