# Docker: Why does logging in on one Ignition instance cause log out on other Ignition instances?

**URL:** <https://forum.inductiveautomation.com/t/docker-why-does-logging-in-on-one-ignition-instance-cause-log-out-on-other-ignition-instances/78839>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [September 7, 2023, 12:10am UTC](https://forum.inductiveautomation.com/t/docker-why-does-logging-in-on-one-ignition-instance-cause-log-out-on-other-ignition-instances/78839 "2023-09-07T00:10:00Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![tyler.bennett](https://avatars.discourse-cdn.com/v4/letter/t/f04885/32.png) [@tyler.bennett](https://forum.inductiveautomation.com/u/tyler.bennett)\
**Post date:** [September 7, 2023, 12:10am UTC](https://forum.inductiveautomation.com/t/docker-why-does-logging-in-on-one-ignition-instance-cause-log-out-on-other-ignition-instances/78839/1 "2023-09-07T00:10:00Z")

</div>

I'm staging multiple instances of Ignition in docker containers to test server redundancy and Enterprise Admin Module features (EAM). I am using docker compose to create multiple Ignition apps/instances. I am using Chrome and have a tab for each Ignition instance's gateway page. I notice that when I start to authenticate on one Ignition instance I am automatically logged out of the other instances though my aim was to have concurrent access to the gateway config on each instance.

Any idea's on why the Ignition instances are having this unintended cross-impact on other instances and how to resolve it. Note that starting authentication on an incognito browser session does not seem to have the same impact on a non-incognito Ignition session... so perhaps this is more an artifact of Chrome sessions rather than Ignition itself?

Note that these observation are still valid before any other configuration is applied to the Ignition gateways.

Docker compose file:

```auto
services:

  gwa:
    # See https://hub.docker.com/r/inductiveautomation/ignition
    # See https://docs.inductiveautomation.com/display/DOC81/Docker+Image
    image: inductiveautomation/ignition:8.1.31
    restart: always
    hostname: dev-ha-gwa
    ports:
      - "9022:8088"
    volumes:
      - gw_a_data:/usr/local/bin/ignition/data
    environment:
      - ACCEPT_IGNITION_EULA=Y
      - IGNITION_EDITION=standard
      - GATEWAY_ADMIN_USERNAME=admin
      - GATEWAY_ADMIN_PASSWORD=ignition
    command: >
      -n 'HA-A'

  gwb:
    # See https://hub.docker.com/r/inductiveautomation/ignition
    # See https://docs.inductiveautomation.com/display/DOC81/Docker+Image
    image: inductiveautomation/ignition:8.1.31
    restart: always
    hostname: dev-ha-gwb
    ports:
      - "9024:8088"
    volumes:
      - gw_b_data:/usr/local/bin/ignition/data
    environment:
      - ACCEPT_IGNITION_EULA=Y
      - IGNITION_EDITION=standard
      - GATEWAY_ADMIN_USERNAME=admin
      - GATEWAY_ADMIN_PASSWORD=ignition
    command: >
      -n 'HA-B'

volumes:
  gw_a_data:
  gw_b_data:

```

---

<div class="post-metadata">

**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\
**Post date:** [September 7, 2023, 12:36am UTC](https://forum.inductiveautomation.com/t/docker-why-does-logging-in-on-one-ignition-instance-cause-log-out-on-other-ignition-instances/78839/2 "2023-09-07T00:36:34Z")

</div>

Try using alternative hostnames to reference your gateways. You can use a service like [\*.localtest.me](https://readme.localtest.me/). So in your example, try opening tabs against [http://gwa.localtest.me:9022](http://gwa.localtest.me:9022) and [http://gwb.localtest.me:9024](http://gwb.localtest.me:9024) .. You should be able to maintain individual logins to those now that you're using different hostnames (each resolving to localhost / 127.0.0.1).

---

<div class="post-metadata">

**Author:** ![tyler.bennett](https://avatars.discourse-cdn.com/v4/letter/t/f04885/32.png) [@tyler.bennett](https://forum.inductiveautomation.com/u/tyler.bennett)\
**Post date:** [September 7, 2023, 4:42pm UTC](https://forum.inductiveautomation.com/t/docker-why-does-logging-in-on-one-ignition-instance-cause-log-out-on-other-ignition-instances/78839/3 "2023-09-07T16:42:17Z")

</div>

Thanks, my mind was headed in that direction. However the docker containers are hosted on a project dev server, not on my local computer so something like [\*.localtest.me](https://readme.localtest.me/) won't work for my use case. I can add multiple names to the hosts file for the same IP address on my computer (and will) but that provides a solution only for me and not a general solution for any/all team members that might access the docker containers on the same server (unless I have them do the same).

I suppose I could look deeper into something like implementing a reverse-proxy ([traefik](https://traefik.io/traefik/)) on that server to route access to the various docker container provisioned services by name. I am not greatly familiar with implementing that, just aware of it. I believe that would rely on having name resolution working (e.g. DNS) and thus far we have just been using IP address with port connection to access the docker containers.

Does Chrome not recognize the port connection as distinguishing connections to different services?  
e.g. `<ip address>::8088` vs. `<ip address>::9022`

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [September 7, 2023, 4:48pm UTC](https://forum.inductiveautomation.com/t/docker-why-does-logging-in-on-one-ignition-instance-cause-log-out-on-other-ignition-instances/78839/4 "2023-09-07T16:48:03Z")

</div>

I don't think this is Chrome-specific, but rather how [HTTP cookies are specified](https://www.rfc-editor.org/rfc/rfc6265).

In particular:

> Similarly, cookies for a given host are shared  
> across all the ports on that host, even though the usual "same-origin  
> policy" used by web browsers isolates content retrieved via different  
> ports.

---

<div class="post-metadata">

**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\
**Post date:** [September 7, 2023, 4:54pm UTC](https://forum.inductiveautomation.com/t/docker-why-does-logging-in-on-one-ignition-instance-cause-log-out-on-other-ignition-instances/78839/5 "2023-09-07T16:54:45Z")

</div>

> [@tyler.bennett](#):
>
> However the docker containers are hosted on a project dev server, not on my local computer so something like [\*.localtest.me](https://readme.localtest.me/) won't work for my use case.

In the meantime, you can get the equivalent via [sslip.io](https://sslip.io/). The URLs are a bit more cumbersome, but it will get you that same unique hostname.

---

<div class="post-metadata">

**Author:** ![robby.tanner](https://avatars.discourse-cdn.com/v4/letter/r/c6cbf5/32.png) [@robby.tanner](https://forum.inductiveautomation.com/u/robby.tanner)\
**Post date:** [July 8, 2024, 9:16pm UTC](https://forum.inductiveautomation.com/t/docker-why-does-logging-in-on-one-ignition-instance-cause-log-out-on-other-ignition-instances/78839/6 "2024-07-08T21:16:02Z")

</div>

This fixed the same issue I was having on localhost while following through the Docker tutorial. Thanks!!