How to set up OctoPrint to autologin a single user when connecting from the internal network

Starting with OctoPrint 1.5.0, OctoPrint makes enabled access control mandatory. This might be an inconvience for some who run OctoPrint in an isolated setup where a login is not required to ensure security, at a benefit for a huge number of users out there who continue to underestimate or simply ignore the risk of keeping their OctoPrint instance unsecured and then happily exposing it on the public internet. And frankly, it will also make me sleep better at night.

That being said, even as far back as OctoPrint 1.0.0 (released in 2013) there has existed a way to have OctoPrint automatically log you in, if you connect from a trusted local network address. This functionality has not been exposed on the UI, and for now also won't be (to make it a bit harder to once again create an insecure setup for those who simply won't listen to common sense), but it's easy to set up with a bit of configuration editing.

When set up properly, it will make sure to automatically log you in as a configured user whenever you connect from a device on your local network. To get back pretty much the same behaviour as with disabled access control, you'll only need to create a single (admin) account and then set up autologin for it.

:raised_hand: Do not do this if you cannot trust EVERYONE on your local network. And I really mean everyone. If you ignore this and then someone takes over your OctoPrint instance, installs malware on it and makes your printer print an endless stream of benchies, that's on you.

The easy way: Using the OctoPrint-AutoLoginConfig plugin

Install the following plugin via the plugin manager:

Open its settings and follow the instructions on the screen.

The hard way: Manual editing of config.yaml


First of all, read the YAML primer in the docs please - you will have to edit OctoPrint's main configuration file, and thus should make sure you understand at least roughly how things work and that you should keep your hands off the Tab key. If you don't, you might break your config file, and while I'll tell you to make a backup, this still can be easily avoided by educating yourself on the DOs and DONTs first.

Then, take a look at the docs on config.yaml and where to find that central configuration file of OctoPrint:

If not specified via the command line, the main configuration file config.yaml for OctoPrint is expected in its settings folder, which unless defined differently via the command line is located at ~/.octoprint on Linux, at %APPDATA%/OctoPrint on Windows and at ~/Library/Application Support/OctoPrint on macOS.

Next you need to collect some information. In order to enable autologin, we'll need to know

  • The username you want to automatically get logged in as - that is what you use for logging into OctoPrint's web interface. This will be what you put where it says <yourUsername> below.

  • The ip address range of your LAN - sounds scary, but actually isn't. Just figure out your PC's IP address and subnet mask and then combine both with a / in between.

  • On OctoPi (or another Linux distribution) you can use the following command:
    ip route | grep -P 'eth0|wlan0' | awk '{print $1}' or for IPV6:
    ip -6 route | grep -P 'eth0|wlan0' | awk '{print $1}'

    This will be what you put where it says <yourAddressRange> below.

    E.g.: Your PC has an IP address of and a subnet mask of Your address range is


Ready? Let's do some editing then. I'll outline what to do and where first, and then further down there's also a dedicated list of steps for OctoPi specifically.

  1. Shutdown OctoPrint
  2. Make a backup of your config.yaml.
  3. Open it in a text editor (e.g. nano). Right at the very top it'll say something like this:
        salt: aabbccddee1234523452345
    Add to this a bunch of lines so it looks like this (make absolutely sure to not touch the salt line!):
        salt: aabbccddee1234523452345
        autologinLocal: true
        autologinAs: "<yourUsername>"
        - ""
        - "<yourAddressRange>"
  4. Restart OctoPrint, check that everything works.

This will automatically log you in as the user you specified whenever you connect to OctoPrint from an address in the address range (e.g. a device on your local network).

OctoPi specific steps

If you are running OctoPi you will have to SSH into your Raspberry Pi (username: pi, default password: raspberry, but you hopefully changed that - if not, do so right away please via sudo raspi-config!). Then:

  1. sudo service octoprint stop
  2. cp ~/.octoprint/config.yaml ~/.octoprint/config.yaml.back
  3. nano ~/.octoprint/config.yaml, make the edits as described above
  4. sudo service octoprint start

If something went wrong, you can restore the config backup with

cp ~/.octoprint/config.yaml.back ~/.octoprint/config.yaml

For those of you that are not network savy, the <yourAddressRange> mentioned above is in CIDR notation format.

1 Like

@jneilliii mentioned that under "Preparation", but added your link there now too - a bit more info can't hurt :slight_smile:

1 Like

Sorry fossel.. no really super savvy so forgive me if I am off, but I think your example on CIDR format is wrong.. you are suggesting ... should it not be `' in that case?

Will this work if VPN running? Obviously non-local adress is used but local adddress is still valid?

You are right, we switched from CIDR to subnet mask representation for the guide during RC testing, but I forgot to fix that. Just to clarify, and are functionally equivalent AFAIK, but is easier to determine from existing IP settings of the OS, even without a knowledge of subnet sizes and IP address representation.

The "easy way" also will do validation against what you enter to help you get it right.

1 Like

Will both representations work when editing config.yaml?
I tried CIDR as per snippets and seems to work (working other issues with my upgrade so cannot be totally sure, but see no errors re login)
(And since I have your attention, tks for Octoprint.. it is awesome)

1 Like

Both representations work, and both are accepted by the AAL Config plugin.

1 Like

I added (as a third bullet) an alternate method of determining the local CIDR using a shell command. I'm not sure this is the best way to convey the idea that you should use either bullet 2 or bullet 3 but you don't need to do both.