{"id":14364994,"url":"https://github.com/will-moss/isaiah","last_synced_at":"2026-03-01T01:04:16.625Z","repository":{"id":215513794,"uuid":"738746027","full_name":"will-moss/isaiah","owner":"will-moss","description":"Self-hostable clone of lazydocker for the web. Manage your Docker fleet with ease","archived":false,"fork":false,"pushed_at":"2025-08-07T21:00:22.000Z","size":6450,"stargazers_count":1070,"open_issues_count":3,"forks_count":21,"subscribers_count":9,"default_branch":"master","last_synced_at":"2025-08-22T06:47:30.928Z","etag":null,"topics":["docker","self-hosted"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/will-moss.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2024-01-04T00:24:47.000Z","updated_at":"2025-08-15T15:10:52.000Z","dependencies_parsed_at":"2024-02-03T04:24:45.203Z","dependency_job_id":"fadef131-3fcc-41cc-9a40-78c6f2ef1a57","html_url":"https://github.com/will-moss/isaiah","commit_stats":null,"previous_names":["will-moss/isaiah"],"tags_count":59,"template":false,"template_full_name":null,"purl":"pkg:github/will-moss/isaiah","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/will-moss%2Fisaiah","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/will-moss%2Fisaiah/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/will-moss%2Fisaiah/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/will-moss%2Fisaiah/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/will-moss","download_url":"https://codeload.github.com/will-moss/isaiah/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/will-moss%2Fisaiah/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29957128,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-28T22:53:01.873Z","status":"ssl_error","status_checked_at":"2026-02-28T22:52:50.699Z","response_time":90,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["docker","self-hosted"],"created_at":"2024-08-27T18:01:04.894Z","updated_at":"2026-03-01T01:04:16.598Z","avatar_url":"https://github.com/will-moss.png","language":"Go","funding_links":[],"categories":["Go"],"sub_categories":[],"readme":"\u003cp align=\"center\"\u003e\n    \u003ch1 align=\"center\"\u003eIsaiah\u003c/h1\u003e\n    \u003cp align=\"center\"\u003e\n      Self-hostable clone of lazydocker for the web.\u003cbr /\u003eManage your Docker fleet with ease\n    \u003c/p\u003e\n    \u003cp align=\"center\"\u003e\n      \u003ca href=\"#table-of-contents\"\u003eTable of Contents\u003c/a\u003e -\n      \u003ca href=\"#deployment-and-examples\"\u003eInstall\u003c/a\u003e -\n      \u003ca href=\"#configuration\"\u003eConfigure\u003c/a\u003e\n    \u003c/p\u003e\n\u003c/p\u003e\n\n| | | |\n|:-------------------------:|:-------------------------:|:-------------------------:|\n|\u003cimg width=\"1604\" src=\"/assets/CAPTURE-1.png\"/\u003e |  \u003cimg width=\"1604\" src=\"/assets/CAPTURE-2.png\"/\u003e | \u003cimg width=\"1604\" src=\"/assets/CAPTURE-3.png\" /\u003e |\n|\u003cimg width=\"1604\" src=\"/assets/CAPTURE-4.png\"/\u003e |  \u003cimg width=\"1604\" src=\"/assets/CAPTURE-5.png\"/\u003e | \u003cimg width=\"1604\" src=\"/assets/CAPTURE-6.png\" /\u003e |\n|\u003cimg width=\"1604\" src=\"/assets/CAPTURE-7.png\"/\u003e |  \u003cimg width=\"1604\" src=\"/assets/CAPTURE-8.png\"/\u003e | \u003cimg width=\"1604\" src=\"/assets/CAPTURE-9.png\" /\u003e |\n|\u003cimg width=\"1604\" src=\"/assets/CAPTURE-10.png\"/\u003e |  \u003cimg width=\"1604\" src=\"/assets/CAPTURE-11.png\"/\u003e | \u003cimg width=\"1604\" src=\"/assets/CAPTURE-12.png\"/\u003e |\n|\u003cimg width=\"1604\" src=\"/assets/CAPTURE-13.png\"/\u003e |  \u003cimg width=\"1604\" src=\"/assets/CAPTURE-14.png\"/\u003e | \u003cimg width=\"1604\" src=\"/assets/CAPTURE-15.png\"/\u003e |\n\n## Table of Contents\n\n- [Introduction](#introduction)\n- [Features](#features)\n- [Deployment and Examples](#deployment-and-examples)\n  * [Deploy with Docker](#deploy-with-docker)\n  * [Deploy with Docker Compose](#deploy-with-docker-compose)\n  * [Deploy as a standalone application](#deploy-as-a-standalone-application)\n    + [Using an existing binary](#using-an-existing-binary)\n    + [Building the binary manually](#building-the-binary-manually)\n    + [Updating](#updating)\n- [Multi-node deployment](#multi-node-deployment)\n  * [General information](#general-information)\n  * [Setup](#setup)\n- [Multi-host deployment](#multi-host-deployment)\n  * [General information](#general-information-1)\n  * [Setup](#setup-1)\n- [Forward Proxy Authentication / Trusted SSO](#forward-proxy-authentication--trusted-sso)\n- [Configuration](#configuration)\n- [Theming](#theming)\n- [Troubleshoot](#troubleshoot)\n- [Security](#security)\n- [Disclaimer](#disclaimer)\n- [Contribute](#contribute)\n- [Credits](#credits)\n\n## Introduction\n\nIsaiah is a self-hostable service that enables you to manage all your Docker resources on a remote server. It is an attempt at recreating the [lazydocker](https://github.com/jesseduffield/lazydocker) command-line application from scratch, while making it available as a web application without compromising on the features.\n\n\n## Features\n\nIsaiah has all these features implemented :\n- For stacks :\n    - Bulk update, Bulk pause, Bulk unpause, Bulk restart, Bulk down\n    - Up, Down, Pause, Unpause, Stop, Restart, Update\n    - Create and Edit stacks using `docker-compose.yml` files in your browser\n    - Inspect (live logs, `docker-compose.yml`, services)\n- For containers :\n    - Bulk stop, Bulk remove, Bulk restart, Bulk update, Prune\n    - Remove, Pause, Unpause, Restart, Rename, Update, Edit, Open in browser\n    - Open a shell inside the container (from your browser)\n    - Inspect (live logs, stats, env, full configuration, top)\n- For images :\n    - Prune\n    - Remove\n    - Run (create and start a container using the image)\n    - Open on Docker Hub\n    - Pull a new image (from Docker Hub)\n    - Bulk pull all latest images (from Docker Hub)\n    - Inspect (full configuration, layers)\n- For volumes :\n    - Prune\n    - Remove\n    - Browse volume files (from your browser, via shell)\n    - Inspect (full configuration)\n- For networks :\n    - Prune\n    - Remove\n    - Inspect (full configuration)\n- Built-in automatic Docker host discovery\n- Built-in authentication by master password (supplied raw or sha256-hashed)\n- Built-in authentication by forward proxy authentication headers (e.g. Authelia / Trusted SSO)\n- Built-in terminal emulator (with support for opening a shell on the server)\n- Responsive for Desktop, Tablet, and Mobile\n- Support for multiple layouts\n- Support for custom CSS theming (with variables for colors already defined)\n- Support for keyboard navigation\n- Support for mouse navigation\n- Support for search through Docker resources and container logs\n- Support for ascending and descending sort by any supported field\n- Support for customizable user settings (line-wrap, timestamps, prompt, etc.)\n- Support for custom Docker Host / Context.\n- Support for extensive configuration with `.env`\n- Support for HTTP and HTTPS\n- Support for standalone / proxy / multi-node / multi-host deployment\n\nOn top of these, one may appreciate the following characteristics :\n- Written in Go (for the server) and Vanilla JS (for the client)\n- Holds in a ~4 MB single file executable\n- Holds in a ~4 MB Docker image\n- Works exclusively over Websocket, with very little bandwidth usage\n- Uses the official Docker SDK for 100% of the Docker features\n\nFor more information, read about [Configuration](#configuration) and [Deployment](#deployment-and-examples).\n\n\n## Deployment and Examples\n\n\u003e Please make sure that Docker 23.0.0+ is installed before proceeding, or consider updating beforehand.\n\n\u003e If you are using the Stacks feature to manage Docker Compose stacks, please use Docker 26.0.0+.\n\n\u003e The default password is : one-very-long-and-mysterious-secret\n\n### Deploy with Docker\n\nYou can run Isaiah with Docker on the command line very quickly.\n\nYou can use the following commands :\n\n```sh\n# Create a .env file\ntouch .env\n\n# Edit .env file ...\n\n# Option 1 : Run Isaiah attached to the terminal (useful for debugging)\ndocker run \\\n  --env-file .env \\\n  -v /var/run/docker.sock:/var/run/docker.sock:ro \\\n  -p \u003cYOUR-PORT-MAPPING\u003e \\\n  mosswill/isaiah\n\n# Option 2 : Run Isaiah as a daemon\ndocker run \\\n  -d \\\n  --env-file .env \\\n  -v /var/run/docker.sock:/var/run/docker.sock:ro \\\n  -p \u003cYOUR-PORT-MAPPING\u003e \\\n  mosswill/isaiah\n\n# Option 3 : Quick run with default settings\ndocker run -v /var/run/docker.sock:/var/run/docker.sock:ro -p 3000:3000 mosswill/isaiah\n```\n\n\u003e Note : Since version 1.36.2, all the Docker images are also mirrored on Github. You can run from `ghcr.io/will-moss/isaiah:latest`\n\n### Deploy with Docker Compose\n\nTo help you get started quickly, multiple example `docker-compose` files are located in the [\"examples/\"](examples) directory.\n\nHere's a description of every example :\n\n- `docker-compose.simple.yml`: Run Isaiah as a front-facing service on port 80., with environment variables supplied in the `docker-compose` file directly.\n\n- `docker-compose.volume.yml`: Run Isaiah as a front-facing service on port 80, with environment variables supplied as a `.env` file mounted as a volume.\n\n- `docker-compose.ssl.yml`:  Run Isaiah as a front-facing service on port 443, listening for HTTPS requests, with certificate and private key provided as mounted volumes.\n\n- `docker-compose.proxy.yml`: A full setup with Isaiah running on port 80, behind a proxy listening on port 443.\n\n- `docker-compose.traefik.yml`: A sample setup with Isaiah running on port 80, behind a Traefik proxy listening on port 443.\n\n- `docker-compose.agent.yml`: A sample setup with Isaiah operating as an Agent in a multi-node deployment.\n\n- `docker-compose.host.yml`: A sample setup with Isaiah expecting to communicate with other hosts in a multi-host deployment.\n\nWhen your `docker-compose` file is on point, you can use the following commands :\n```sh\n# Option 1 : Run Isaiah in the current terminal (useful for debugging)\ndocker-compose up\n\n# Option 2 : Run Isaiah in a detached terminal (most common)\ndocker-compose up -d\n\n# Show the logs written by Isaiah (useful for debugging)\ndocker logs \u003cNAME-OF-YOUR-CONTAINER\u003e\n```\n\n\u003e Warning : Always make sure that your Docker Unix socket is mounted, else Isaiah won't be able to communicate with the Docker API.\n\n\u003e Note : Since version 1.36.2, all the Docker images are also mirrored on Github. You can pull from `ghcr.io/will-moss/isaiah:latest`\n\n### Deploy as a standalone application\n\nYou can deploy Isaiah as a standalone application, either by downloading an existing binary that fits your architecture,\nor by building the binary yourself on your machine.\n\n#### Using an existing binary\n\nAn install script was created to help you install Isaiah in one line, from your terminal :\n\n\u003e As always, check the content of every file you pipe in bash\n\n```sh\n# Multiple options are provided to cater to differences between\n# operating systems and versions of curl.\n\n# Option 1:\nbash \u003c(curl -s https://raw.githubusercontent.com/will-moss/isaiah/master/scripts/remote-install.sh)\n\n# Option 2:\ncurl -s https://raw.githubusercontent.com/will-moss/isaiah/master/scripts/remote-install.sh \u003e install.sh\nchmod 755 install.sh\n./install.sh\n```\n\nThis script will try to automatically download a binary that matches your operating system and architecture, and put it\nin your `/usr/[local/]bin/` directory to ease running it. Later on, you can run :\n\n```sh\n# Create a new .env file\ntouch .env\n\n# Edit .env file ...\n\n# Run Isaiah\nisaiah\n\n# Check current version\nisaiah -v\n\n```\n\nIn case you feel uncomfortable running the install script, you can head to the `Releases`, find the binary that meets your system, and install it yourself.\n\n#### Building the binary manually\n\nIn this case, make sure that your system meets the following requirements :\n- You have Go 1.21 installed\n- You have Node 20+ installed along with npm and npx\n\nWhen all the prerequisites are met, you can run the following commands in your terminal :\n\n\u003e As always, check the content of everything you run inside your terminal\n\n```sh\n# Retrieve the code\ngit clone https://github.com/will-moss/isaiah\ncd isaiah\n\n# Run the local install script\n./scripts/local-install.sh\n\n# Move anywhere else, and create a dedicated directory\ncd ~\nmkdir isaiah-config\ncd isaiah-config\n\n# Create a new .env file\ntouch .env\n\n# Edit .env file ...\n\n# Option 1 : Run Isaiah in the current terminal\nisaiah\n\n# Option 2 : Run Isaiah as a background process\nisaiah \u0026\n\n# Option 3 : Run Isaiah using screen\nscreen -S isaiah\nisaiah\n\u003cCTRL+A\u003e \u003cD\u003e\n\n# Optional : Remove the cloned repository\n# cd \u003cback to the cloned repository\u003e\n# rm -rf ./isaiah\n```\n\nThe local install script will try to perform a production build on your machine, and move `isaiah` to your `/usr/[local/]bin/` directory\nto ease running it. In more details, the following actions are performed :\n- Local install of Babel, LightningCSS, Less, and Terser\n- Prefixing, Transpilation, and Minification of CSS and JS assets\n- Building of the Go source code into a single-file executable (with CSS and JS embed)\n- Cleaning of the artifacts generated during the previous steps\n- Removal of the previous `isaiah` executable, if any in `/usr/[local/]bin/`\n- Moving the new `isaiah` executable in `/usr/[local/]bin` with `755` permissions.\n\nIf you encounter any issue during this process, please feel free to tweak the install script or reach out by opening an issue.\n\n#### Updating\n\nYou can update your `isaiah` executable by running the install script once again, or by performing the steps to build it manually once again.\nBoth procedures will take care of overwriting any existing executable.\n\n\u003e For Docker deployments, just pull the latest image and recreate your container / stack.\n\n## Multi-node deployment\n\nUsing Isaiah, you can manage multiple nodes with their own distinct Docker resources from a single dashboard.\n\nBefore delving into that part, please get familiar with the general information below.\n\n### General information\n\nYou may find these information useful during your setup and reading :\n- Isaiah distinguishes two types of nodes : `Master` and `Agent`.\n- The word `node` refers to any machine (virtual or not) holding Docker resources.\n- The `Master` node has three responsabilities :\n  - Serving the web interface.\n  - Managing the Docker resources inside the environment on which it is already installed.\n  - Acting as a central proxy between the client (you) and the remote Agent nodes.\n- The `Master` node has the following characteristics :\n  - There should be only one Master node in a multi-node deployment.\n  - The Master node should be the only part of your deployment that is publicly exposed on the network.\n- The `Agent` nodes have the following characteristics :\n  - They are headless instances of Isaiah, and they can't exist without a Master node.\n  - As with the Master node, they have their own authentication if you don't disable it explicitly.\n  - On startup, they perform registration with their Master node using as a Websocket client\n  - For as long as the Master node is alive, a Websocket connection remains established between them.\n  - The Agent node should never be publicly exposed on the network.\n  - The Agent node never communicates with the client (you). Everything remains between the nodes.\n  - There is no limit to how many Agent nodes can connect to a Master node.\n\nIn other words, one `Master` acts as a `Proxy` between the `Client` and the `Agents`.\u003cbr /\u003e\nFor example, when a `Client` wants to stop a Docker container inside an `Agent`, the `Client` first requests it from `Master`.\nThen, `Master` forwards it to the designated `Agent`.\nWhen the `Agent` has finished, they reply to `Master`, and `Master` forwards that response to the initial `Client`.\n\nSchematically, it looks like this :\n- Client ------------\u003e Master : Stop container C-123 on Agent AG-777\n- Master ------------\u003e Agent  : Stop container C-123\n- Agent  ------------\u003e Master : Container C-123 was stopped\n- Master ------------\u003e Client : Container C-123 was stopped on Agent AG-777\n\nNow that we understand how everything works, let's see how to set up a multi-node deployment.\n\n### Setup\n\nFirst, please ensure the following :\n- Your `Master` node is running, exposed on the network, and available in your web browser\n- Your `Agent` node has Isaiah installed and configured with the following settings :\n  - `SERVER_ROLE` equal to `Agent`\n  - `MASTER_HOST` configured to reach the `Master` node\n  - `MASTER_SECRET` equal to the `AUTHENTICATION_SECRET` setting on the `Master` node, or empty when authentication is disabled\n  - `AGENT_NAME` equal to a unique string of your choice\n\nThen, launch Isaiah on each `Agent` node, and you should see logs indicating whether connection with `Master` was established. Eventually, you will see `Master` or `The name of your agent` in the lower right corner of your screen as agents register.\n\nIf encounter any issue, please read the [Troubleshoot](#troubleshoot) section.\n\n\u003e You may want to note that you don't need to expose ports on the machine / Docker container running Isaiah when it is configured as an Agent.\n\n\u003e **Feature:** When Master and Agent nodes have the same secret, no authentication prompt will be required after logging into Master\n\n### Additional notes on configuration\n\nPlease note that, in a multi-node deployment, the following affirmations about the configuration are true :\n- The configuration settings that have no comment about multi-node deployments are all both available for Master and Agent nodes, except for `SSL_ENABLED` and `SERVER_PORT` since Agent nodes do not behave like a server that listens for incoming connections.\n    - So, for instance, you could have a different `TABS_ENABLED` setting for each node, regardless of them being a Master or Agent.\n    - These settings were all designed to work in a single-node deployment initially, without multi-node enabled at all, but they also work in a multi-node deployment transparently due to how the code is written.\n- The configuration settings that have a comment about multi-node deployments will be interpreted only in a multi-node deployment, and fully ignored in a single-node deployment. Even more so, they are absolutely required for a multi-node deployment to work. And the ones that mention \"for Agent node\" will be fully ignored by the Master node.\n- For the only configuration setting that mentions \"for both Master and Agent nodes\", which is `SERVER_ROLE`, this is just a requirement for the code to identify \"Who is a Master? Who is an Agent?\" at startup, and it is interpreted only in a multi-node deployment.\n\nYou may want to check the issue [#19](https://github.com/will-moss/isaiah/issues/19) to learn more about that part.\n\n\n## Multi-host deployment\n\nUsing Isaiah, you can manage multiple hosts with their own distinct Docker resources from a single dashboard.\n\nBefore delving into that part, please get familiar with the general information below.\n\n### General information\n\nThe big difference between multi-node and multi-host deployments is that you won't need to install Isaiah on every single node\nif you are using multi-host. In this setup, Isaiah is installed only on one server, and communicates with other Docker hosts\ndirectly over TCP / Unix sockets. It makes it easier to manage multiple remote Docker environments without having to setup Isaiah\non all of them.\n\n\u003e In a multi-host deployment, Isaiah sends requests directly to the `/var/run/docker.sock` socket on the remote machines. So, that file must\nbe exposed in one way or another.\n\nPlease note that, in a multi-host setup, there must be a direct access between the main host (where Isaiah is running)\nand the other ones. Usually, they should be on the same network, or visible through a secured gateway / VPN / filesystem mount.\n\nLet's see how to set up a multi-host deployment.\n\n### Setup\n\nIn order to help you get started, a [sample file](/app/sample.docker_hosts) was created.\n\nFirst, please ensure the following :\n- Your `Master` host is running, exposed on the network, and available in your web browser\n- Your `Master` host has the setting `MULTI_HOST_ENABLED` set to `true`.\n- Your `Master` host has access to the other Docker hosts over TCP / Unix socket.\n\nSecond, please create a `docker_hosts` file next to Isaiah's executable, using the sample file cited above:\n- Every line should contain two strings separated by a single space.\n- The first string is the name of your host, and the second string is the path to reach it.\n- The path to your host should look like this : [PROTOCOL]://[URI]\n- Example 1 : Local unix:///var/run/docker.sock\n- Example 2 : Remote tcp://my-domain.tld:4382\n\n\u003e If you're using Docker, you can mount the file at the root of the filesystem, as in :\u003cbr /\u003e\n`docker ... -v my_docker_hosts:/docker_hosts ...`\n\nFinally, launch Isaiah on the Master host, and you should see logs indicating whether connection with remote hosts was established.\nEventually, you will see `Master` with `The name of your host` in the lower right corner of your screen.\n\n## Forward Proxy Authentication / Trusted SSO\n\nIf you wish to deploy Isaiah behind a secure proxy or authentication portal, you must configure Forward Proxy Authentication.\n\nThis will enable you to :\n- Log in, once and for all, into your authentication portal.\n- Connect to Isaiah without having to type your `AUTHENTICATION_SECRET` every time.\n- Protect Isaiah using your authentication proxy rather than the current mechanism (cleartext / hashed password).\n- Manage the access to Isaiah from your authentication portal rather than through your `.env` configuration.\n\nBefore proceeding, please ensure the following :\n- Your proxy supports HTTP/2 and Websockets.\n- Your proxy can communicate with Isaiah on the network.\n- Your proxy forwards authentication headers to Isaiah (but not to the browser).\n\n\u003cblockquote\u003e\n  \u003cbr /\u003e\n  For example, if you're using Nginx Proxy Manager (NPM), you should do the following :\n  \u003cbr /\u003e\u003cbr /\u003e\n  \u003cul\u003e\n    \u003cli\u003eIn the tab \"Details\"\u003c/li\u003e\n    \u003cul\u003e\n      \u003cli\u003eTick the box \"Websockets support\"\u003c/li\u003e\n      \u003cli\u003eTick the box \"HTTP/2 support\"\u003c/li\u003e\n      \u003cli\u003eTick the box \"Block common exploits\"\u003c/li\u003e\n      \u003cli\u003eTick the box \"Force SSL\"\u003c/li\u003e\n   \u003c/ul\u003e\n   \u003cbr /\u003e\n   \u003cli\u003eIn the tab \"Advanced\"\u003c/li\u003e\n   \u003cul\u003e\n      \u003cli\u003eIn your custom location block, add the lines :\u003c/li\u003e\n      \u003cul\u003e\n        \u003cli\u003eproxy_set_header Upgrade $http_upgrade;\u003c/li\u003e\n        \u003cli\u003eproxy_set_header Connection \"upgrade\";\u003c/li\u003e\n      \u003c/ul\u003e\n    \u003c/ul\u003e\n  \u003c/ul\u003e\n  \u003cbr /\u003e\n\u003c/blockquote\u003e\n\nThen, configure Isaiah using the following variables :\n- Set `FORWARD_PROXY_AUTHENTICATION_ENABLED` to `true`.\n- Set `FORWARD_PROXY_AUTHENTICATION_HEADER_KEY` to the name of the forwarded authentication header your proxy sends to Isaiah.\n- Set `FORWARD_PROXY_AUTHENTICATION_HEADER_VALUE` to the value of the header that Isaiah should expect (or use `*` if all values are accepted).\n\n\u003e By default, Isaiah is configured to work with Authelia out of the box. Hence, you can just set `FORWARD_PROXY_AUTHENTICATION_ENABLED` to `true` and be done with it.\n\nIf everything was properly set up, you will encounter the following flow :\n- Navigate to `isaiah.your-domain.tld`.\n- Get redirected to `authentication-portal.your-domain.tld`.\n- Fill in your credentials.\n- Authentication was successful.\n- Get redirected to `isaiah.your-domain.tld`.\n- Isaiah **does not** prompt you for the password, you're automatically logged in.\n\n\n## Configuration\n\nTo run Isaiah, you will need to set the following environment variables in a `.env` file located next to your executable :\n\n\u003e **Note :** Regular environment variables provided on the commandline work too\n\n\u003e **Note :** Boolean values are case-insensitive, and can be represented via \"ON\" / \"OFF\" / \"TRUE\" / \"FALSE\" / 0 / 1.\n\n| Parameter               | Type      | Description                | Default |\n| :---------------------- | :-------- | :------------------------- | ------- |\n| `SSL_ENABLED`           | `boolean` | Whether HTTPS should be used in place of HTTP. When configured, Isaiah will look for `certificate.pem` and `key.pem` next to the executable for configuring SSL. Note that if Isaiah is behind a proxy that already handles SSL, this should be set to `false`. | False        |\n| `SERVER_PORT`           | `integer` | The port Isaiah listens on. | 3000        |\n| `SERVER_MAX_READ_SIZE`  | `integer` | The maximum size (in bytes) per message that Isaiah will accept over Websocket. Note that, in a multi-node deployment, you may need to incrase the value of that setting. (Shouldn't be modified, unless your server randomly restarts the Websocket session for no obvious reason) | 100000        |\n| `SERVER_CHUNKED_COMMUNICATION_ENABLED`  | `boolean` | Whether resources should be sent in chunks, rather than all at once. (Recommended only in setups with 150+ Docker resources, and multi-node deployments) | False        |\n| `SERVER_CHUNKED_COMMUNICATION_SIZE`  | `integer` | The number of resources to send per chunk, when chunked communication is enabled | 50        |\n| `AUTHENTICATION_ENABLED`| `boolean` | Whether a password is required to access Isaiah. (Recommended) | True |\n| `AUTHENTICATION_SECRET` | `string`  | The master password used to secure your Isaiah instance against malicious actors. | one-very-long-and-mysterious-secret        |\n| `AUTHENTICATION_HASH`   | `string`  | The master password's hash (sha256 format) used to secure your Isaiah instance against malicious actors. Use this setting instead of `AUTHENTICATION_SECRET` if you feel uncomfortable providing a cleartext password. | Empty    |\n| `DISPLAY_CONFIRMATIONS` | `boolean` | Whether the web interface should display a confirmation message after every succesful operation. | True |\n| `TABS_ENABLED`          | `string`  | Comma-separated list of tabs to display in the interface. (Case-insensitive) (Available: Stacks, Containers, Images, Volumes, Networks) | stacks,containers,images,volumes,networks |\n| `COLUMNS_CONTAINERS`    | `string`  | Comma-separated list of fields to display in the `Containers` panel. (Case-sensitive) (Available: ID, State, ExitCode, Name, Image, Created) | State,ExitCode,Name,Image |\n| `COLUMNS_IMAGES`        | `string`  | Comma-separated list of fields to display in the `Images` panel. (Case-sensitive) (Available: UsageState, ID, Name, Version, Size) | UsageState,Name,Version,Size |\n| `COLUMNS_VOLUMES`       | `string`  | Comma-separated list of fields to display in the `Volumes` panel. (Case-sensitive) (Available: Name, Driver, MountPoint) | Driver,Name |\n| `COLUMNS_NETWORKS`      | `string`  | Comma-separated list of fields to display in the `Networks` panel. (Case-sensitive) (Available: ID, Name, Driver) | Driver,Name |\n| `COLUMNS_STACKS`        | `string`  | Comma-separated list of fields to display in the `Stacks` panel. (Case-sensitive) (Available: Name, Status) | Status,Name |\n| `SORTBY_CONTAINERS`     | `string`  | Field used to sort the rows in the `Containers` panel. (Case-sensitive) (Available: ID, State, ExitCode, Name, Image, Created) | Empty |\n| `SORTBY_IMAGES`         | `string`  | Field used to sort the rows in the `Images` panel. (Case-sensitive) (Available: ID, Name, Version, Size) | Empty |\n| `SORTBY_VOLUMES`        | `string`  | Field used to sort the rows in the `Volumes` panel. (Case-sensitive) (Available: Name, Driver, MountPoint) | Empty |\n| `SORTBY_NETWORKS`       | `string`  | Field used to sort the rows in the `Networks` panel. (Case-sensitive) (Available: Id, Name, Driver) | Empty |\n| `SORTBY_STACKS`         | `string`  | Field used to sort the rows in the `Stacks` panel. (Case-sensitive) (Available: Name, Status) | Empty |\n| `CONTAINER_HEALTH_STYLE`| `string`  | Style used to display the containers' health state. (Available: long, short, icon)| long |\n| `CONTAINER_LOGS_TAIL`   | `integer` | Number of lines to retrieve when requesting the last container logs | 50 |\n| `CONTAINER_LOGS_SINCE`  | `string`  | The amount of time from now to use for retrieving the last container logs | 60m |\n| `STACKS_DIRECTORY`      | `string`  | The path to the directory that will be used to store the `docker-compose.yml` files generated while creating and editing stacks. It must be a valid path to an existing and writable directory. | `.` (current directory) |\n| `TTY_SERVER_COMMAND`    | `string`  | The command used to spawn a new shell inside the server where Isaiah is running | `/bin/sh -i` |\n| `TTY_CONTAINER_COMMAND` | `string`  | The command used to spawn a new shell inside the containers that Isaiah manages | `/bin/sh -c eval $(grep ^$(id -un): /etc/passwd \\| cut -d : -f 7-) -i` |\n| `CUSTOM_DOCKER_HOST`    | `string`  | The host to use in place of the one defined by the DOCKER_HOST default variable | Empty |\n| `CUSTOM_DOCKER_CONTEXT` | `string`  | The Docker context to use in place of the current Docker context set on the system | Empty |\n| `SKIP_VERIFICATIONS`    | `boolean` | Whether Isaiah should skip startup verification checks before running the HTTP(S) server. (Not recommended) | False        |\n| `SERVER_ROLE`           | `string`  | For multi-node deployments only, for both Master and Agent nodes. The role of the current instance of Isaiah. Can be either `Master` or `Agent` and is case-sensitive. | Master        |\n| `MASTER_HOST`           | `string`  | For multi-node deployments only, for Agent nodes. The host used to reach the Master node, specifying the IP address or the hostname, and the port if applicable (e.g. my-server.tld:3000). | Empty        |\n| `MASTER_SECRET`         | `string`  | For multi-node deployments only, for Agent nodes. The secret password used to authenticate on the Master node. Note that it should equal the `AUTHENTICATION_SECRET` setting on the Master node. | Empty        |\n| `AGENT_NAME`            | `string`  | For multi-node deployments only, for Agent nodes. The name associated with the Agent node as it is displayed on the web interface. It should be unique for each Agent. | Empty        |\n| `AGENT_REGISTRATION_RETRY_DELAY`  | `integer`  | For multi-node deployments only, for Agent nodes. The delay (in seconds) between reconnection attempts when the connection to the Master node was lost. | 30        |\n| `MULTI_HOST_ENABLED`    | `boolean` | Whether Isaiah should be run in multi-host mode. When enabled, make sure to have your `docker_hosts` file next to the executable. | False        |\n| `FORWARD_PROXY_AUTHENTICATION_ENABLED`    | `boolean` | Whether Isaiah should accept authentication headers from a forward proxy. | False        |\n| `FORWARD_PROXY_AUTHENTICATION_HEADER_KEY` | `string` | The name of the authentication header sent by the forward proxy after a succesful authentication. | Remote-User        |\n| `FORWARD_PROXY_AUTHENTICATION_HEADER_VALUE` | `string` | The value accepted by Isaiah for the authentication header. Using `*` means that all values are accepted (except emptiness). This parameter can be used to enforce that only a specific user or group can access Isaiah (e.g. `admins` or `john`). | * |\n| `CLIENT_PREFERENCE_XXX` | `string` | Please read [this troubleshooting paragraph](#the-web-interface-does-not-save-my-preferences). These settings enable you to define your client preferences on the server, for when your browser can't use the `localStorage` due to limitations, or private browsing. | Empty |\n\n\u003e **Note :** To sort rows in reverse using the `SORTBY_` parameters, prepend your field with the minus symbol, as in `-Name`\n\n\u003e **Note :** Use either `AUTHENTICATION_SECRET` or `AUTHENTICATION_HASH` but not both at the same time.\n\n\u003e **Note** : You can generate a sha256 hash using an online tool, or using the following commands :\n**On OSX** : `echo -n your-secret | shasum -a 256`\n**On Linux** : `echo -n your-secret | sha256sum`\n\nAdditionally, once Isaiah is fully set up and running, you can open the Parameters Manager by pressing the `X` key.\nUsing this interface, you can toggle the following options based on your preferences :\n\n| Parameter               | Description                |\n| :---------------------- | :------------------------- |\n| `enableMenuPrompt`      | Whether an extra prompt should warn you before trying to stop / pause / restart a Docker container. |\n| `enableLogLinesWrap`    | Whether log lines streamed from Docker containers should be wrapped (as opposed to extend beyond your screen). |\n| `enableTimestampDisplay`| Whether log lines' timestamps coming from Docker containers should be displayed. |\n| `enableOverviewOnLaunch`| Whether an overview panel should show first before anything when launching Isaiah in your browser. |\n| `enableLogLinesStrippedBackground`| Whether alternated log lines should have a brighter background to enhance readability. |\n| `enableJumpFuzzySearch` | Whether, in Jump mode, fuzzy search should be used, as opposed to default substring search. |\n| `enableSyntaxHightlight`| Whether syntax highlighting should be enabled (when viewing docker-compose.yml files). |\n\n\u003e Note : You must have Isaiah open in your browser and be authenticated to access these options. Once set up, these options will be saved to your localStorage.\n\n\n## Theming\n\nYou can customize Isaiah's web interface using your own custom CSS. At runtime, Isaiah will look for a file named `custom.css` right next to the executable.\nIf this file exists, it will be loaded in your browser and it will override any existing CSS rule.\n\nIn order to help you get started, a [sample file](/app/sample.custom.css) was created.\nIt shows how to modify the CSS variables responsible for the colors of the interface. (All the values are the ones used by default)\nYou can copy that file, update it, and rename it to `custom.css`.\n\nIf you're using Docker, you should mount a `custom.css` file at the root of your container's filesystem.\nExample : `docker ... -v my-custom.css:/custom.css ...`\n\nFinally, you will find below a table that describes what each CSS color variable means :\n\n| Variable                | Description                |\n| :---------------------- | :--------                  |\n| `color-terminal-background` | Background of the interface |\n| `color-terminal-base` | Texts of the interface |\n| `color-terminal-accent` | Elements that are interactive or must catch the attention |\n| `color-terminal-accent-selected` | Panel's title when the panel is in focus |\n| `color-terminal-hover` | Panel's rows that are in focus / hover |\n| `color-terminal-border` | Panels' borders color |\n| `color-terminal-danger` | The color used to convey danger / failure |\n| `color-terminal-warning` | Connection indicator when connection is lost |\n| `color-terminal-accent-alternative` | Connection indicator when connection is established |\n| `color-terminal-log-row-alternative` | The color used as background for each odd row in the logs tab |\n| `color-terminal-json-key` | The color used to distinguish keys from values in the inspector when displaying a long configuration |\n| `color-terminal-json-value` | The color used to distinguish values from keys in the inspector when displaying a long configuration |\n| `color-terminal-cell-failure` | Container health state when exited |\n| `color-terminal-cell-success` | Container health state when running |\n| `color-terminal-cell-paused` | Container health state when paused |\n\nOn a side note, creating custom layouts using only CSS isn't implemented yet as it requires interaction with Javascript.\nThat said, implementing this feature should be quick and simple since the way layouts are managed currently is already modular.\n\nUltimately, please note that Isaiah already comes with three themes : dawn, moon, and the default one.\nThe first two themes are based on Rosé Pine, and new themes may be implemented later.\n\n## Troubleshoot\n\nShould you encounter any issue running Isaiah, please refer to the following common problems with their solutions.\n\n#### Isaiah is unreachable over HTTP / HTTPS\n\nPlease make sure that the following requirements are met :\n\n- If Isaiah runs as a standalone application without proxy :\n    - Make sure your server / firewall accepts incoming connections on Isaiah's port.\n    - Make sure your DNS configuration is correct. (Usually, such record should suffice : `A isaiah XXX.XXX.XXX.XXX` for `https://isaiah.your-server-tld`)\n    - Make sure your `.env` file is well configured according to the [Configuration](#configuration) section.\n\n- If Isaiah runs on Docker :\n    - Perform the previous (standalone) verifications first.\n    - Make sure you mounted your server's Docker Unix socket onto the container that runs Isaiah (/var/run/docker.sock)\n    - Make sure your Docker container is accessible remotely\n\n- If Isaiah runs behind a proxy :\n    - Perform the previous (standalone) verifications first.\n    - Make sure that `SERVER_PORT` (Isaiah's port) are well set in `.env`.\n    - Check your proxy forwarding rules.\n\nIn any case, the crucial part is [Configuration](#configuration) and making sure your Docker / Proxy setup is correct as well.\n\n\n#### On startup, Isaiah shows 0 containers, 0 networks, 0 volumes, and 0 images\n\nYou must update Docker on your system to fix that issue.\n\nIsaiah uses the native Docker Engine API, and it requires Docker to be at least on version 23.0.0+\n\n#### On a system with a lot of Docker resources, Isaiah is inconsistent or crashes\n\nThis is due to a limitation on the message size during the WebSocket communication.\nWhen your server has a lot of Docker resources on it (~150+), Isaiah will send all these resources in a single\nWebSocket message by default. This can cause the server to crash.\n\nThere are two solutions :\n- Increase the maximum size of a message : Increase the value of the setting `SERVER_MAX_READ_SIZE`\n- Enabled chunked communication : Set `SERVER_CHUNKED_COMMUNICATION_ENABLED` to `TRUE` and adjust `SERVER_CHUNKED_COMMUNICATION_SIZE` if it's not already satisfying.\n\nYou may encounter the same issue in a multi-node deployment, and the cleanest solution here would be to enable chunked communication on the node that hosts a lot of Docker resources.\n\n#### The emulated shell behaves unconsistently or displays unexpected characters\n\nPlease note that the emulated shell works by performing the following steps :\n- Open a headless terminal on the remote server / inside the remote Docker container.\n- Capture standard output, standard error, and bind standard input to the web interface.\n- Display standard output and standard error on the web interface as they are streamed over Websocket from the terminal.\n\nAccording to this implementation, the remote terminal never receives key presses. It only receives commands.\n\nAlso, the following techniques are used to try to enhance the user experience on the web interface :\n- Enable clearing the shell (HTML) screen via \"Ctrl+L\" (while the real terminal remains untouched)\n- Enable quitting the (HTML) shell via \"Ctrl+D\" (by sending an \"exit\" command to the real terminal)\n- Handle \"command mirror\" by appending \"# ISAIAH\" to every command sent by the user (to distinguish it from command output)\n- Handle both \"\\r\" and \"\\n\" newline characters\n- Use a time-based approach to detect when a command is finished if it doesn't output anything that shows clear ending\n- Remove all escape sequences meant for coloring the terminal output\n- Handle up and down arrow keys to cycle through commands history locally\n\nTherefore it appears that, unless we use a VNC-like solution, the emulation can neither be enhanced nor use keyboard-based features (such as tab completion).\n\nUnless a contributor points the project in the right direction, and as far as my skills go, I personally believe that the current implementation has reached its maximum potential.\n\nI leave here a few ideas that I believe could be implemented, but may require more knowledge, time, testing :\n- Convert escape sequences to CSS colors\n- Wrap every command in a \"block\" (begin - command - end) to easily distinguish user-sent commands from output\n- Sending to the real terminal the key presses captured from the web (a.k.a sending key presses to a running process)\n\nUltimately, please also note that in a multi-node / multi-host setup, the extra network latency and unexpected buffering from remote terminals may cause additional display artifacts.\n\n#### An error happens when spawning a new shell on the server / inside a Docker container\n\nThe default commands used to spawn a shell, although being more or less standard, may not fit your environment.\nIn this case, please edit the `TTY_SERVER_COMMAND` and `TTY_CONTAINER_COMMAND` settings to define a command that works better in your setup.\n\nAlso, please note that if you have deployed Isaiah using Docker, trying to open a system shell (`S` key) will not work.\nIsaiah being confined to its Docker container, it won't be able to open a shell out of it (on your hosting system).\n\n#### The connection with the remote server randomly stops or restarts\n\nThis is a known incident that happens when the Websocket server receives a data message that exceeds its maximum read size.\nYou should be able to fix that by updating the `SERVER_MAX_READ_SIZE` setting to a higher value (default is 100,000 bytes).\nThis operation shouldn't cause any problem or impact performances.\n\n#### I can neither click nor use the keyboard, nothing happens\n\nIn such a case, please check the icon in the lower right corner.\nIf you see an orange warning symbol, it means that the connection with the server was lost.\nWhen the connection is lost, all inputs are disabled, until the connection is reestablished (a new attempt is performed every second).\n\n#### The interface is stuck loading indefinitely\n\nThis incident arises when a crash occurs while inside a shell or performing a Docker command.\nThe quickest \"fix\" for that is to refresh your browser tab (Ctrl+R/Cmd+R).\n\nThe real \"fix\" (if any) could be to implement a \"timeout\" (client-side or server-side) after which, the \"loading\" state is automatically discarded\n\nIf you encounter this incident consistently, please reach out by opening an issue so we look deeper into that part\n\n#### The web interface seems to randomly crash and restart\n\nIf you haven't already, please read about the `SERVER_MAX_READ_SIZE` setting in the [Configuration](#configuration) section.\n\nThat incident occurs when the Websocket messages sent from the client to the server are too big.\nThe server's reaction to overly large messages sent over Websocket is to close the connection with the client.\nWhen that happens, Isaiah (as a client in your browser) automatically reopens a connection with the server, hence explaining the \"crash-restart\" cycle.\n\n#### The web interface does not save my preferences\n\nFirst, please ensure that your browser supports the `localStorage` API.\n\nSecond, please ensure that you're not using the `private browsing` or `incognito` or `anonymous browsing` mode. This mode will\nturn off the `localStorage`, hence disabling the user preferences saved by Isaiah in your browser.\n\nIf you wish to use Isaiah inside a private browser window while still having your preferences stored somewhere, use the\n`CLIENT_PREFERENCE_XXX` settings in your deployment. These settings will be stored server-side, and understood by your browser\nwithout ever using `localStorage`, hence circumventing the limitation of the private browsing mode.\n\nAll the preferences described in the second table of [Configuration](#configuration) are available server-side, using their uppercased-underscore counterpart.\nSee below :\n- `theme` becomes `CLIENT_PREFERENCE_THEME`\n- `enableOverviewOnLaunch` becomes `CLIENT_PREFERENCE_ENABLE_OVERVIEW_ON_LAUNCH`\n- `enableMenuPrompt` becomes `CLIENT_PREFERENCE_ENABLE_MENU_PROMPT`\n- `enableLogLinesWrap` becomes `CLIENT_PREFERENCE_ENABLE_LOG_LINES_WRAP`\n- `enableJumpFuzzySearch` becomes `CLIENT_PREFERENCE_ENABLE_JUMP_FUZZY_SEARCH`\n- `enableTimestampDisplay` becomes `CLIENT_PREFERENCE_ENABLE_TIMESTAMP_DISPLAY`\n- `enableLogLinesStrippedBackground` becomes `CLIENT_PREFERENCE_ENABLE_LOG_LINES_STRIPPED_BACKGROUND`\n\n#### I can't see my Docker Stacks (Docker Compose) in the user interface / A feature isn't available\n\nPlease ensure that Isaiah is running on the hosting system directly, and not inside a Docker container.\n\nFor certain features (including, managing Docker Compose projects), Isaiah needs to run commands on the hosting system.\nFor example, it runs `docker compose ls` to find all the Docker Compose projects, or even `docker compose -f FILE up -d` to up a stack.\n\nAs a result, if Isaiah is running inside a Docker container, it won't be able to run those commands on the hosting system.\n\nFor ease of deployment, you may want to use the install script [described here](https://github.com/will-moss/isaiah?tab=readme-ov-file#using-an-existing-binary).\n\n#### A feature that works on desktop is missing from the mobile user interface\n\nPlease note that you can horizontally scroll the mobile controls located in the bottom part of your screen to reveal all of them.\nIf, for any reason, you still encounter a case when a feature is missing on your mobile device, please open an issue\nindicating the browser you're using, your screen's viewport size, and the model of your phone.\n\n#### In a multi-node deployment, the agent's registration with master is stuck loading indefinitely\n\nThis issue arises when the authentication settings between Master and Agent nodes are incompatible.\u003cbr /\u003e\nTo fix it, please make sure that :\n- When authentication is enabled on Master, the Agent has a `MASTER_SECRET` setting defined.\n- When authentication is disabled on Master, the Agent has no `MASTER_SECRET` setting defined.\n\nAlso don't forget to restart your nodes when changing settings.\n\n#### Something else\n\nPlease feel free to open an issue, explaining what happens, and describing your environment.\n\n## Security\n\nDue to the very nature of Isaiah, I can't emphasize enough how important it is to harden your server :\n- Always enable the authentication (with `AUTHENTICATION_ENABLED` and `AUTHENTICATION_SECRET` settings) unless you have your own authentication mechanism built into a proxy.\n- Always use a long and secure password to prevent any malicious actor from taking over your Isaiah instance.\n- You may also consider putting Isaiah on a private network accessible only through a VPN.\n\nKeep in mind that any breach or misconfiguration on your end could allow a malicious actor to fully take over your server.\n\n## Disclaimer\n\nI believe that, although we're both in the open-source sphere and have all the best intentions, it is important to state the following :\n\n- Isaiah isn't a competitor or any attempt at replacing the lazydocker project. Funnily enough, I'm myself more comfortable running lazydocker through SSH rather than in a browser.\n- I've browsed almost all the open issues on lazydocker, and tried to implement and improve what I could (hence the `TTY_CONTAINER_COMMAND` variable, as an example, or even the Image pulling feature).\n- Isaiah was built from absolute zero (for both the server and the client), and was ultimately completed using knowledge from lazydocker that I'm personally missing (e.g. the container states and icons).\n- Before creating Isaiah, I tried to \"serve lazydocker over websocket\" (trying to send keypresses to the lazydocker process, and retrieving the output via Websocket), but didn't succeed, hence the full rewrite.\n- I also tried to start Isaiah from the lazydocker codebase and implement a web interface on top of it, but it seemed impractical or simply beyond my skills, hence the full rewrite.\n\nUltimately, thanks to the people behind lazydocker both for the amazing project (that I'm using daily) and for paving the way for Isaiah.\n\nPS : Please also note that Isaiah isn't exactly 100% feature-equivalent with lazydocker (e.g. charts are missing)\nPS2 : What spurred me to build Isaiah in the first place is a bunch of comments on the Reddit self-hosted community, stating that Portainer and other available solutions were too heavy or hard to use. A Redditor said that having lazydocker over the web would be amazing, so I thought I'd do just that.\n\n## Contribute\n\nThis is one of my first ever open-source projects, and I'm not a Docker / Github / Docker Hub / Git guru yet.\n\nIf you can help in any way, please do! I'm looking forward to learning from you.\n\nFrom the top of my head, I'm sure there's already improvement to be made on :\n- Terminology (using the proper words to describe technical stuff)\n- Coding practices (e.g. writing better comments, avoiding monkey patches)\n- Shell emulation (e.g. improving on what's done already)\n- Release process (e.g. making explicit commits, pushing Docker images properly to Docker Hub)\n- Github settings (e.g. using discussions, wiki, etc.)\n- And more!\n\n## Credits\n\nHey hey ! It's always a good idea to say thank you and mention the people and projects that help us move forward.\n\nBig thanks to the individuals / teams behind these projects :\n- [laydocker](https://github.com/jesseduffield/lazydocker) : Isaiah wouldn't exist if Lazydocker hadn't been created prior, and to say that it is an absolutely incredible and very advanced project is an understatement.\n- [Heroicons](https://github.com/tailwindlabs/heroicons) : For the great icons.\n- [Melody](https://github.com/olahol/melody) : For the awesome Websocket implementation in Go.\n- [GoReleaser](https://github.com/goreleaser/goreleaser) : For the amazing release tool.\n- [Fuse](https://github.com/krisk/fuse) : For the amazing fuzzy-search library.\n- The countless others!\n\nAnd don't forget to mention Isaiah if it makes your life easier!\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwill-moss%2Fisaiah","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fwill-moss%2Fisaiah","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwill-moss%2Fisaiah/lists"}