Fix Open Fleet hostnames

Hello,

Is there a way to fix the hostname of devices for an open fleet so our end-users could access them in a simple way via mDNS (i.e http://myapp.local)?

Thanks in advance

I have seen in some of BalenaLabs open-source repos that you can call the Supervisor API with

# openFleets: configure hostname
curl -X PATCH --header "Content-Type:application/json" \
    --data '{"network": {"hostname": "myapp"}}' \
    "$BALENA_SUPERVISOR_ADDRESS/v1/device/host-config?apikey=$BALENA_SUPERVISOR_API_KEY"

Example available on BalenaSound

This command will return an ‘OK’ response from a container with the label io.balena.features.supervisor-api: 1.
However, could someone confirm that it is not enough to instantly change the hostname and that we also have to reboot the device for the new hostname to be applied? (and for our users to be able to go on http://myapp.local/? Or is there a way to apply it and make it discoverable without rebooting?

Thanks a lot

Hi Pierre, I have just tested this locally running the command you provided within an application’s container, and can confirm that it changed the discoverable hostname insantly to myapp.local

Let us know if you run into any issues with this command

@pcorbel , I wanted to post a link to our hostname block that might be easier to use than running the curl command.

Agreeing with what @mehalter said, it should work right away without a device reboot, but your milage could vary depending on your own network setup/router/etc.

I trigger a reboot after the hostname change. I have found that although the device may change hostname the hostname from within my containers doesn’t. They tend to need to be rebuilt for the container hostname change to appear inside containers. Supervisor takes care of this automatically after rebooting the device, the container will load, after some seconds supervisor will recreate the container.

Having a matching hostname inside the container may not matter to you. But supervisor may at some point restart your container. In general i have found it better to trigger a restart to be sure everything runs smooth.

There is an api endpoint for rebooting the device too.