# config.txt changes are not applying to the host

**URL:** <https://forums.balena.io/t/config-txt-changes-are-not-applying-to-the-host/375388>\
**Category:** Product support\
**Created:** [January 16, 2026, 9:57pm UTC](https://forums.balena.io/t/config-txt-changes-are-not-applying-to-the-host/375388 "2026-01-16T21:57:58Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![bobbrez](https://avatars.discourse-cdn.com/v4/letter/b/b5a626/32.png) [@bobbrez](https://forums.balena.io/u/bobbrez)\
**Post date:** [January 16, 2026, 9:57pm UTC](https://forums.balena.io/t/config-txt-changes-are-not-applying-to-the-host/375388/1 "2026-01-16T21:57:58Z")

</div>

I have a fleet where I’ve updated the default device configuration with a variable am not seeing the update appear on the device. Is my understanding correct that device configuration variables prefixed with `BALENA_HOST_CONFIG_`are applied to the `config.txt` automatically (i.e. setting `BALENA_HOST_CONFIG_isolcpus` to `3` should add an entry into the `config.txt` with `isolcpus=3`)?

I am trying to set the `isolcpus`, trying both `RESIN_HOST_CONFIG_isolcpus` and `BALENA_HOST_CONFIG_isolcpus`. I’ve tried to reboot via the console and power cycling. The fleet has 3 devices, all are identical Raspberry Pi 5s running the latest Host OS (`balenaOS 6.9.4+rev2`). 1 device is in development mode, the other 2 are in production, but all are experiencing the same issue.

On the development device, if I manually update the `/resin-boot/config.txt` with the value, it works as expected.

---

<div class="post-metadata">

**Author:** ![drskullster](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/drskullster/32/10218_2.png) [@drskullster](https://forums.balena.io/u/drskullster)\
**Post date:** [January 27, 2026, 10:13am UTC](https://forums.balena.io/t/config-txt-changes-are-not-applying-to-the-host/375388/2 "2026-01-27T10:13:02Z")

</div>

Hi @bobbrez, and welcome to the forums!

Your understanding is correct: as per our documentation [1] any variable prefixed with `BALENA_HOST_CONFIG_` added via the configuration tab on the dashboard will show up in config.txt. I just tested on a raspberry pi 4 device with `BALENA_HOST_CONFIG_isolcpus` and it works as expected.

Note that the change is visible in `/mnt/boot/config.txt`, whcih is the config file used by the OS, and not `/resin-boot/config.txt` which is a default file that is populated upon provisioning.

When you look at `/mnt/boot/config.txt` are you able to see the value `isolcpus=3`?

[1] [Advanced boot settings | balena](https://docs.balena.io/reference/OS/advanced/#modifying-configtxt-using-configuration-variables)

---

<div class="post-metadata">

**Author:** ![bobbrez](https://avatars.discourse-cdn.com/v4/letter/b/b5a626/32.png) [@bobbrez](https://forums.balena.io/u/bobbrez)\
**Post date:** [March 18, 2026, 7:46pm UTC](https://forums.balena.io/t/config-txt-changes-are-not-applying-to-the-host/375388/3 "2026-03-18T19:46:38Z")

</div>

Thank you for checking. The value in `BALENA_HOST_CONFIG_isolcpus` is making it into `/mnt/boot/config.txt` as expected. I was making an assumption that it would then in tern make it into the `cmdline.txt` as well, but it is not. Although the parameter it is getting set in the `config.txt` it does not actually affect the system unless it is present in `cmdline.txt`

A quick validation is running `cat /sys/devices/system/cpu/isolated` on the host to see if it is blank or the value from the param.

Is there any way to reliably update cmdline from the dashboard?

---

<div class="post-metadata">

**Author:** ![shaunmulligan1](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/shaunmulligan1/32/9857_2.png) [@shaunmulligan1](https://forums.balena.io/u/shaunmulligan1)\
**Post date:** [March 24, 2026, 9:55am UTC](https://forums.balena.io/t/config-txt-changes-are-not-applying-to-the-host/375388/4 "2026-03-24T09:55:00Z")

</div>

Unfortunately we don’t currently support changing cmdline.txt today, this is usually either done via a Custom Device support agreement or hacked by the user mounting the file and changing it from their container (which can be somewhat dangerous). We do have some plans to support this but it won’t happen with in 2026 unfortunately.

---

<div class="post-metadata">

**Author:** ![rahul-thakoor](https://avatars.discourse-cdn.com/v4/letter/r/9de053/32.png) [@rahul-thakoor](https://forums.balena.io/u/rahul-thakoor)\
**Post date:** [April 1, 2026, 1:45pm UTC](https://forums.balena.io/t/config-txt-changes-are-not-applying-to-the-host/375388/7 "2026-04-01T13:45:18Z")

</div>

hello @bobbrez

You might consider using **cpusets** via your `docker-compose.yml` as a runtime alternative.  
Docs: [docker-compose.yml fields | balena docs](https://docs.balena.io/reference/supervisor/docker-compose#supported-fields:~:text=cpu_shares-,cpuset,-depends_on)

While this doesn’t offer 100% parity with the `isolcpus` kernel parameter (as the kernel may still occasionally use the cores for its own internal housekeeping or interrupts), it allows you to effectively partition your CPU resources at the application level.

From my understanding, `isolcpus` tells the kernel scheduler to ignore the cores entirely. `cpuset` simply tells the scheduler where it is _allowed_ to put specific processes.

### Implementation

To achieve an outcome similar to `isolcpus`, you essentially have to “carve out” the cores by restricting your other services. For example, if you want to isolate Core 3 for a specific high-performance task:

1. **Pin your critical service** to Core 3.
2. **Explicitly restrict all other services** to Cores 0-2.

```auto
services:
  high-priority-task:
    image: my-app/worker
    # Isolates this service to the 4th core
    cpuset_cpus: "3" 

  standard-service:
    image: my-app/web
    # Keeps this service off the 4th core
    cpuset_cpus: "0,1,2" 

```

I haven’t tried this personally, though.

Do let us know how it goes 🙂