Skip to main content

App Management

The following article is a primer on managing self-hosted apps. It covers everything from keeping the Dashy (or any other app) up-to-date, secure, backed up, to other topics like auto-starting, monitoring, log management, web server configuration and using custom domains.

Contents​

Providing Assets​

Dashy reads everything for your dashboard from a single host directory mounted into the container at /app/user-data. This is done with a Docker volume, e.g. -v /path/to/your/user-data:/app/user-data.

The directory must contain a conf.yml. It can also contain anything else you want served from the web root: sub-config files for additional pages, item icons, favicon, fonts, custom CSS, manifest, and so on. Any file placed there is reachable at /<filename> in the browser, overriding files of the same name in the bundled public/ defaults.

Typical contents:

  • conf.yml - Main config (required)
  • *.yml / *.yaml - Sub-config files for multi-page support
  • item-icons/ - Local icons referenced by icon: foo.png
  • favicon.ico, manifest.webmanifest, robots.txt - Override the bundled defaults
  • fonts/, widget-resources/ - Custom fonts or assets used by widgets

⬆️ Back to Top

File Ownership and Permissions​

Inside the container, Dashy runs as a non-root user with uid/gid 1000 (the built-in node user from the Node base image). This is fine for the vast majority of installs, since the first user on a default Linux or macOS box is also uid 1000, so a bind-mounted user-data directory is read/writable straight away.

It only gets fiddly if your host uid happens to be something else (NAS systems and multi-user servers being the usual culprits). In that case, config saves from the UI will fail with a permission error, because the container's uid 1000 doesn't own your directory.

There are two ways to sort it. Pick whichever is less hassle:

  1. Run the container as your own user. The cleanest option, since you don't touch host file ownership.

    On docker run:

    docker run -d -p 8080:8080 \
      --user $(id -u):$(id -g) \
      -v /path/to/user-data:/app/user-data \
      lissy93/dashy:latest

    In compose, uncomment the user: line under the service and set it:

    user: "1001:1001"   # whatever `id -u` and `id -g` give you

  2. Hand the directory to uid 1000. Quicker if you don't mind changing host ownership:

    sudo chown -R 1000:1000 /path/to/user-data

If you're on rootless Podman, use --userns=keep-id instead of --user. Rootless Podman maps container uids to a sub-uid range, so without it a directory you own looks root-owned from inside the container.

Note that if you run the container as root (e.g. --user 0:0), Dashy will still work, but you lose the security benefit of a non-root container. Don't do that unless you've a good reason.

⬆️ Back to Top

Running Commands​

If you're running an app in Docker, then commands will need to be passed to the container to be executed. This can be done by preceding each command with docker exec -it [container-id], where container ID can be found by running docker ps. For example docker exec -it 26c156c467b4 yarn validate-config. You can also enter the container, with docker exec -it [container-id] /bin/ash, and navigate around it with normal Linux commands.

Dashy has several commands that can be used for various tasks, you can find a list of these either in the Developing Docs, or by looking at the package.json. These can be used by running yarn [command-name].

⬆️ Back to Top

Healthchecks​

Healthchecks are configured to periodically check that Dashy is up and running correctly on the specified port. By default, the health script is called every 5 minutes, but this can be modified with the --health-interval option. You can check the current container health with: docker inspect --format "{{json .State.Health }}" [container-id], and a summary of health status will show up under docker ps. You can also manually request the current application status by running docker exec -it [container-id] yarn health-check. You can disable healthchecks altogether by adding the --no-healthcheck flag to your Docker run command.

To restart unhealthy containers automatically, check out Autoheal. This image watches for unhealthy containers, and automatically triggers a restart. (This is a stand in for Docker's --exit-on-unhealthy that was proposed, but not merged). There's also Deunhealth, which is super light-weight, and doesn't require network access. Both need access to the Docker socket, see Don't Expose the Docker Daemon Socket for the trade-off.

docker run -d \
    --name autoheal \
    --restart=always \
    -e AUTOHEAL_CONTAINER_LABEL=all \
    -v /var/run/docker.sock:/var/run/docker.sock \
    willfarrell/autoheal

HTTP Healthcheck Endpoint​

Dashy also exposes an unauthenticated HTTP liveness endpoint at /healthz, which returns a 200 with a small JSON body (status, uptime, version). It bypasses auth and SSL redirection so probes keep working regardless of how Dashy is configured.

Useful when fronting Dashy with a load balancer / reverse proxy that needs an HTTP probe for auto-failover, or when running on Kubernetes:

# Kubernetes
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
# Traefik (label on the Dashy service)
- "traefik.http.services.dashy.loadbalancer.healthcheck.path=/healthz"
- "traefik.http.services.dashy.loadbalancer.healthcheck.interval=30s"
# Caddy (reverse_proxy block)
reverse_proxy dashy:8080 {
    health_uri  /healthz
    health_interval 30s
}

⬆️ Back to Top

Logs and Performance​

Container Logs​

You can view logs for a given Docker container with docker logs [container-id], add the --follow flag to stream the logs. For more info, see the Logging Documentation. There's also Dozzle, a useful tool, that provides a web interface where you can stream and query logs from all your running containers from a single web app.

Container Performance​

You can check the resource usage for your running Docker containers with docker stats or docker stats [container-id]. For more info, see the Stats Documentation. There's also cAdvisor, a useful web app for viewing and analyzing resource usage and performance of all your running containers.

Management Apps​

You can also view logs, resource usage and other info as well as manage your entire Docker workflow in third-party Docker management apps. For example Portainer an all-in-one open source management web UI for Docker and Kubernetes, or LazyDocker a terminal UI for Docker container management and monitoring.

Advanced Logging and Monitoring​

Docker supports using Prometheus to collect logs, which can then be visualized using a platform like Grafana. For more info, see this guide. If you need to route your logs to a remote syslog, then consider using logspout. For enterprise-grade instances, there are managed services, that make monitoring container logs and metrics very easy, such as Sematext with Logagent.

⬆️ Back to Top

Auto-Starting at System Boot​

You can use Docker's restart policies to instruct the container to start after a system reboot, or restart after a crash. Just add the --restart=always flag to your Docker compose script or Docker run command. For more information, see the docs on Starting Containers Automatically.

For Podman, use Quadlet to run your container as a systemd service. A similar approach can be used with Docker, if you need to start containers after a reboot, but before any user interaction.

To restart the container after something within it has crashed, consider using docker-autoheal by @willfarrell, a service that monitors and restarts unhealthy containers. For more info, see the Healthchecks section above.

⬆️ Back to Top

Updating​

Dashy is under active development, so to take advantage of the latest features, you may need to update your instance every now and again.

Updating Docker Container​

  1. Pull latest image: docker pull lissy93/dashy:latest
  2. Kill off existing container
    • Find container ID: docker ps
    • Stop container: docker stop [container_id]
    • Remove container: docker rm [container_id]
  3. Spin up new container: docker run [params] lissy93/dashy

Or if you're using Docker Compose, it's just docker compose pull && docker compose up -d.

Automatic Docker Updates​

You can automate the above process using Watchtower. Watchtower will watch for new versions of a given image on Docker Hub, pull down your new image, gracefully shut down your existing container and restart it with the same options that were used when it was deployed initially. Note that the original containrrr/watchtower project was archived in December 2025, so use the maintained fork linked above (nickfedor/watchtower on Docker Hub), which is a drop-in replacement.

To get started, spin up the watchtower container (it needs the Docker socket too):

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  nickfedor/watchtower

For more information, see the Watchtower Docs

Updating Dashy from Source​

Stop your current instance of Dashy, then navigate into the source directory. Pull down the latest code, with git pull origin master, then update dependencies with yarn, rebuild with yarn build, and start the server again with yarn start.

Upgrading Across Major Versions​

Major releases can include breaking changes, so skim the release notes before jumping versions. The two that catch most people out:

  • v3 moved all user files (config, icons, etc) into a single user-data directory, mounted at /app/user-data, replacing the old /app/public/conf.yml mount.
  • v4 made the container run as a non-root user (uid 1000). If your mounted user-data isn't writable by that uid, config saves from the UI will fail. See File Ownership and Permissions.

To check a download is genuine, see Verifying Releases.

⬆️ Back to Top

Backing Up​

Dashy-Specific Backup​

All configuration and dashboard settings are stored in your user-data/conf.yml file. If you provide additional assets (like icons, fonts, themes, etc), these will also live in the user-data directory. So to backup all Dashy data, this is the only directory you need to backup.

When you save config through the UI, Dashy automatically creates a timestamped backup in user-data/config-backups/ (configurable via the BACKUP_DIR env var). If you break your config, check that directory for a recent copy. Backups can be disabled by setting DISABLE_CONFIG_BACKUPS=true (e.g. on read-only filesystems or where permissions don't allow it).

Since Dashy is open source, there shouldn't be any need to backup the main container.

Dashy also has a built-in cloud backup feature, which is free for personal users, and will let you make and restore fully encrypted backups of your config directly through the UI. To learn more, see the Cloud Backup Docs

Backing Up Volumes​

offen/docker-volume-backup is a useful tool for periodic Docker volume backups, to any S3-compatible storage provider. It's run as a light-weight Docker container, and is easy to setup, and also supports GPG-encryption, email notification, and routing away older backups.

To get started, create a docker-compose similar to the example below, and then start the container. For more info, check out their documentation, which is very clear.

services:
  backup:
    image: offen/docker-volume-backup:latest
    environment:
      BACKUP_CRON_EXPRESSION: "0 * * * *"
      BACKUP_PRUNING_PREFIX: backup-
      BACKUP_RETENTION_DAYS: 7
      AWS_BUCKET_NAME: backup-bucket
      AWS_ACCESS_KEY_ID: AKIAIOSFODNN7EXAMPLE
      AWS_SECRET_ACCESS_KEY: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
    volumes:
      - data:/backup/my-app-backup:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
volumes:
  data:

It's worth noting that this process can also be done manually, using the following commands:

Backup:

docker run --rm -v some_volume:/volume -v /tmp:/backup alpine tar -cjf /backup/some_archive.tar.bz2 -C /volume ./

Restore:

docker run --rm -v some_volume:/volume -v /tmp:/backup alpine sh -c "rm -rf /volume/* /volume/..?* /volume/.[!.]* ; tar -C /volume/ -xjf /backup/some_archive.tar.bz2"

⬆️ Back to Top

Scheduling​

If you need to periodically schedule the running of a given command on Dashy (or any other container), then a useful tool for doing so it ofelia. This runs as a Docker container and is really useful for things like backups, logging, updating, notifications, etc. Crons are specified using Go's crontab format, and a useful tool for visualizing this is crontab.guru. This can also be done natively with Alpine: docker run -it alpine ls /etc/periodic. I recommend combining this with healthchecks for easy monitoring of jobs, and failure notifications.

⬆️ Back to Top

SSL Certificates​

Enabling HTTPS with an SSL certificate is recommended, especially if you are hosting Dashy anywhere other than your home. This will ensure that all traffic is encrypted in transit.

Auto-SSL​

If you are using NGINX Proxy Manager, then SSL is supported out of the box. Once you've added your proxy host and web address, then set the scheme to HTTPS, then under the SSL Tab select "Request a new SSL certificate" and follow the on-screen instructions.

If you're hosting Dashy behind Cloudflare, then they offer free and easy SSL- all you need to do is enable it under the SSL/TLS tab. Or if you are using shared hosting, you may find this tutorial helpful.

Getting an SSL Certificate​

Let's Encrypt is a global Certificate Authority, providing free SSL/TLS Domain Validation certificates in order to enable secure HTTPS access to your website. They have good browser/ OS compatibility, support wildcard certificates via DNS-01, and provide CertBot, an easy app for generating and setting up an SSL certificate.

This process can be automated, using something like the Docker-NGINX-Auto-SSL Container to generate and renew certificates when needed.

If you're not so comfortable on the command line, then you can use a tool like ZeroSSL to generate your cert. They also provide step-by-step setup instructions for most platforms.

Passing an SSL Certificate to Dashy​

Once you've generated your SSL cert, you'll need to pass it to Dashy. This can be done by specifying the paths to your public and private keys using the SSL_PRIV_KEY_PATH and SSL_PUB_KEY_PATH environmental variables. Or if you're using Docker, then just pass public + private SSL keys in under /etc/ssl/certs/dashy-pub.pem and /etc/ssl/certs/dashy-priv.key respectively, e.g:

docker run -d \
  -p 8080:8080 \
  -v ~/my-private-key.key:/etc/ssl/certs/dashy-priv.key:ro \
  -v ~/my-public-key.pem:/etc/ssl/certs/dashy-pub.pem:ro \
  lissy93/dashy:latest

Dashy runs as uid 1000 inside the container, so both files need to be readable by that user (Certbot's private keys are root-only by default). If the key can't be read, Dashy will still start on HTTP but HTTPS silently won't, with an EACCES error in the logs.

By default the SSL port is 443 within a Docker container, or 4001 if running on bare metal, but you can override this with the SSL_PORT environmental variable.

Once everything is setup, you can verify your site is secured using a tool like SSL Checker.

⬆️ Back to Top

Authentication​

Dashy has built-in auth (users defined in your config), and supports Keycloak and any OIDC provider (Authentik, Authelia, Zitadel, Pocket ID, etc), header auth from a reverse proxy, and HTTP basic auth on the server endpoints. Usage instructions for all of these, as well as alternative auth methods, are on the Authentication Docs page.

⬆️ Back to Top

Network Exposure​

Dashy is designed to run on your local network, behind your firewall. If you only access it from within your home or over a VPN, the defaults are fine.

If you do need to expose Dashy to the internet, you should put it behind a reverse proxy with its own authentication layer (e.g. Authelia, Authentik, Cloudflare Access, or your proxy's built-in auth). Don't rely solely on Dashy's built-in auth for internet-facing instances - it's a convenience feature for private networks, not a hardened perimeter control. See the Authentication Docs for setup options.

When Dashy runs in server mode (the default Docker setup), it exposes several API endpoints for things like status checks, ping checks, config saving, system info, and a CORS proxy used by widgets. When authentication is enabled (via ENABLE_HTTP_AUTH=true or BASIC_AUTH_USERNAME/BASIC_AUTH_PASSWORD env vars), all of these endpoints require valid credentials. Without auth configured, they are open. That's fine for private networks, but not appropriate for public access.

The CORS proxy (/cors-proxy) is worth calling out specifically: it forwards requests from the Dashy server to external URLs, so widgets can reach APIs that don't set CORS headers. On a private network this is harmless, but on an internet-exposed instance without auth, it could be abused as an open proxy. Always enable authentication if your instance is reachable from untrusted networks.

If you don't use widgets or status checks, you can disable the endpoints which make outbound requests (/status-check, /ping-check and /cors-proxy) entirely, by setting the DISABLE_PROXY_ENDPOINTS=true environmental variable. They will then respond with a 403 error, and never make an external request.

⬆️ Back to Top

Managing Containers with Docker Compose​

When you have a lot of containers, it quickly becomes hard to manage with docker run commands. The solution to this is docker compose, a handy tool for defining all a containers run settings in a single YAML file, and then spinning up that container with a single short command - docker compose up. A good example of which can be seen in @abhilesh's docker compose collection.

You can use Dashy's default docker-compose.yml file as a template, and modify it according to your needs.

An example Docker compose, using the default base image from DockerHub, might look something like this:

services:
  dashy:
    container_name: Dashy
    image: lissy93/dashy:latest
    volumes:
      - ./user-data:/app/user-data
    ports:
      - 4000:8080
    restart: unless-stopped
    healthcheck:
      test: ['CMD', 'node', '/app/services/healthcheck.js']
      interval: 1m30s
      timeout: 10s
      retries: 3
      start_period: 30s

⬆️ Back to Top

Passing in Environmental Variables​

With Docker, you can define environmental variables under the environment section of your Docker compose file, or with the --env flag on docker run (or --env-file if you've got many). They're used for server-level settings, read before the config file is loaded. All are optional.

VariableDescription
PORTPort to listen on. Defaults to 8080 in Docker
USER_DATA_DIRPath to the user data directory. Defaults to user-data
BACKUP_DIRWhere config backups are written. Defaults to user-data/config-backups
DISABLE_CONFIG_BACKUPSSet to true to skip the backup made before each config save
ENABLE_HTTP_AUTHSet to true to require the users defined in conf.yml on all server endpoints
BASIC_AUTH_USERNAME / BASIC_AUTH_PASSWORDAlternatively, protect the server endpoints with a single static login
DISABLE_PROXY_ENDPOINTSSet to true to turn off the status check, ping check and CORS proxy endpoints
ENABLE_APISet to true to enable the REST API, see the API Docs
API_TOKENBearer token granting full API access
SSL_PRIV_KEY_PATH / SSL_PUB_KEY_PATHPaths to your SSL key and certificate, see SSL Certificates
SSL_PORTHTTPS port. Defaults to 443 in Docker
REDIRECT_HTTPSSet to false to stop HTTP redirecting to HTTPS when SSL is enabled

Anything starting with VITE_ is a build-time variable, baked in when the app is compiled, so it has no effect on the published image. If you need one of those (e.g. VITE_APP_ROUTING_MODE=hash), you'll need to build your own container. The full list is in the developing docs.

⬆️ Back to Top

Setting Headers​

Any external requests made to a different origin (app/ service under a different domain) will be blocked if the correct headers are not specified. This is known as Cross-Origin Resource Sharing (CORS) and is a security feature built into modern browsers.

Note that widgets fetch data through Dashy's own server-side proxy (useProxy: true), which avoids CORS entirely. And embedding a service in an iframe (workspace view or modals) is controlled by that service's X-Frame-Options / Content-Security-Policy: frame-ancestors headers, not CORS.

If you see a CORS error in your console, this can be easily fixed by setting the correct headers. This is not a bug with Dashy, so please don't raise it as a bug!

Example Headers​

The following section briefly outlines how you can set headers for common web proxies/ servers. More info can be found in the documentation for the proxy that you are using, or in the MDN Docs.

These examples are using:

  • Access-Control-Allow-Origin header, but depending on what type of content you are enabling, this will vary. For example, to allow a site to be loaded in an iframe (for the modal or workspace views) you would use X-Frame-Options.
  • The domain root (/), if your're hosting from a sub-page, replace that with your path.
  • A wildcard (*), which would allow access from traffic on any domain, this is discouraged, and you should replace it with the URL where you are hosting Dashy. Note that for requests that transport sensitive info, like credentials (e.g. Keycloak login), the wildcard is disallowed all together and will be blocked.

Caddy​

See Caddy header docs for more info.

headers / {
  Access-Control-Allow-Origin *
}

NGINX​

See NGINX ngx_http_headers_module docs for more info.

location / {
  add_header Access-Control-Allow-Origin *;
}

Note this can also be done through the UI, using NGINX Proxy Manager.

Traefik​

See TrΓ¦fΙͺk CORS headers docs for more info.

labels:
  - "traefik.http.middlewares.testheader.headers.accesscontrolallowmethods=GET,OPTIONS,PUT"
  - "traefik.http.middlewares.testheader.headers.accesscontrolalloworiginlist=https://foo.bar.org,https://example.org"
  - "traefik.http.middlewares.testheader.headers.accesscontrolmaxage=100"
  - "traefik.http.middlewares.testheader.headers.addvaryheader=true"

HAProxy​

See HAProxy Rewrite Response Docs for more info.

/
   http-response add-header Access-Control-Allow-Origin *

Apache​

See Apache mode_headers docs for more info.

Header always set Access-Control-Allow-Origin "*"

Squid​

See Squid request_header_access docs for more info.

request_header_access Authorization allow all

⬆️ Back to Top

Remote Access​

WireGuard​

Using a VPN is one of the easiest ways to provide secure, full access to your local network from remote locations. WireGuard is a reasonably new open source VPN protocol, that was designed with ease of use, performance and security in mind. Unlike OpenVPN, it doesn't need to recreate the tunnel whenever connection is dropped, and it's also much easier to setup, using shared keys instead.

  • Install Wireguard - See the Install Docs for download links + instructions
    • On Debian-based systems, it's sudo apt install wireguard
  • Generate a Private Key - Run wg genkey on the Wireguard server, and copy it to somewhere safe for later
  • Create Server Config - Open or create a file at /etc/wireguard/wg0.conf and under [Interface] add the following (see example below):
    • Address - as a subnet of all desired IPs
    • PrivateKey - that you just generated
    • ListenPort - Default is 51820, but can be anything
  • Get Client App - Download the WG client app for your platform (Linux, Windows, MacOS, Android or iOS are all supported)
  • Create new Client Tunnel - On your client app, there should be an option to create a new tunnel, when doing so a client private key will be generated (but if not, use the wg genkey command again), and keep it somewhere safe. A public key will also be generated, and this will go in our saver config
  • Add Clients to Server Config - Head back to your wg0.conf file on the server, create a [Peer] section, and populate the following info
    • AllowedIPs - List of IP address inside the subnet, the client should have access to
    • PublicKey - The public key for the client you just generated
  • Start the Server - You can now start the WG server, using: wg-quick up wg0 on your server
  • Finish Client Setup - Head back to your client device, and edit the config file, leave the private key as is, and add the following fields:
    • PublicKey - The public key of the server
    • Address - This should match the AllowedIPs section on the servers config file
    • DNS - The DNS server that'll be used when accessing the network through the VPN
    • Endpoint - The hostname or IP + Port where your WG server is running (you may need to forward this in your firewall's settings)
  • Done - Your clients should now be able to connect to your WG server :) Depending on your networks firewall rules, you may need to port forward the address of your WG server

Example Server Config​

# Server file
[Interface]
# Which networks does my interface belong to? Notice: /24 and /64
Address = 10.5.0.1/24, 2001:470:xxxx:xxxx::1/64
PrivateKey = xxx
ListenPort = 51820

# Peer 1
[Peer]
PublicKey = xxx
# Which source IPs can I expect from that peer? Notice: /32 and /128
AllowedIps = 10.5.0.35/32, 2001:470:xxxx:xxxx::746f:786f/128

# Peer 2
[Peer]
PublicKey = xxx
# Which source IPs can I expect from that peer? This one has a LAN which can
# access hosts/jails without NAT.
# Peer 2 has a single IP address inside the VPN: it's 10.5.0.25/32
AllowedIps = 10.5.0.25/32,10.21.10.0/24,10.21.20.0/24,10.21.30.0/24,10.31.0.0/24,2001:470:xxxx:xxxx::ca:571e/128

Example Client Config​

[Interface]
# Which networks does my interface belong to? Notice: /24 and /64
Address = 10.5.0.35/24, 2001:470:xxxx:xxxx::746f:786f/64
PrivateKey = xxx

# Server
[Peer]
PublicKey = xxx
# I want to route everything through the server, both IPv4 and IPv6. All IPs are
# thus available through the Server, and I can expect packets from any IP to
# come from that peer.
AllowedIPs = 0.0.0.0/0, ::0/0
# Where is the server on the internet? This is a public address. The port
# (:51820) is the same as ListenPort in the [Interface] of the Server file above
Endpoint = 1.2.3.4:51820
# Usually, clients are behind NAT. to keep the connection running, keep alive.
PersistentKeepalive = 15

A useful tool for getting WG setup is Algo. It includes scripts and docs which cover almost all devices, platforms and clients, and has best practices implemented, and security features enabled. All of this is better explained in this blog post.

Reverse SSH Tunnel​

SSH (or Secure Shell) is a secure tunnel that allows you to connect to a remote host. Unlike the VPN methods, an SSH connection does not require an intermediary, and will not be affected by your IP changing. However it only allows you to access a single service at a time. SSH was really designed for terminal access, but because of the latter mentioned benefits it's useful to setup, as a fallback option.

Directly SSH'ing into your home, would require you to open a port (usually 22), which would be terrible for security, and is not recommended. However a reverse SSH connection is initiated from inside your network. Once the connection is established, the port is redirected, allowing you to use the established connection to SSH into your home network.

The issue you've probably spotted, is that most public, corporate, and institutional networks will block SSH connections. To overcome this, you'd have to establish a server outside of your homelab that your homelab's device could SSH into to establish the reverse SSH connection. You can then connect to that remote server (the mothership), which in turn connects to your home network.

Now all of this is starting to sound like quite a lot of work, but this is where services like remot3.it come in. They maintain the intermediary mothership server, and create the tunnel service for you. It's free for personal use, secure and easy. There are several similar services, such as RemoteIoT, or you could create your own on a cloud VPS (see this tutorial for more info on that).

Before getting started, you'll need to head over to Remote.it and create an account.

Then setup your local device:

  1. If you haven't already done so, you'll need to enable and configure SSH.
    • This is out-of-scope of this article, but I've explained it in detail in this post.
  2. Download the Remote.it install script from their GitHub
    • curl -LkO https://raw.githubusercontent.com/remoteit/installer/master/scripts/auto-install.sh
  3. Make it executable, with chmod +x ./auto-install.sh, and then run it with sudo ./auto-install.sh
  4. Finally, configure your device, by running sudo connectd_installer and following the on-screen instructions

And when you're ready to connect to it:

  1. Login to app.remote.it, and select the name of your device
  2. You should see a list of running services, click SSH
  3. You'll then be presented with some SSH credentials that you can now use to securely connect to your home, via the Remote.it servers

Done :)

TCP Tunnel​

If you're running Dashy on your local network, behind a firewall, but need to temporarily share it with someone external, this can be achieved quickly and securely using Ngrok. It's basically a super slick, encrypted TCP tunnel that provides an internet-accessible address that anyone use to access your local service, from anywhere.

To get started, Download and install Ngrok for your system, then just run ngrok http [port] (replace the port with the http port where Dashy is running, e.g. 8080). When using https, specify the full local url/ ip including the protocol.

Some Ngrok features require you to be authenticated, you can create a free account and generate a token in your dashboard, then run ngrok authtoken [token].

It's recommended to use authentication for any publicly accessible service. Dashy has an Auth feature built in, but an even easier method it to use the -auth switch. E.g. ngrok http -auth="username:password123" 8080

By default, your web app is assigned a randomly generated ngrok domain, but you can also use your own custom domain. Under the Domains Tab of your Ngrok dashboard, add your domain, and follow the CNAME instructions. You can now use your domain, with the -hostname switch, e.g. ngrok http -region=us -hostname=dashy.example.com 8080. If you don't have your own domain name, you can instead use a custom sub-domain (e.g. alicia-dashy.ngrok.io), using the -subdomain switch.

To integrate this into your docker-compose, take a look at the gtriggiano/ngrok-tunnel container.

There's so much more you can do with Ngrok, such as exposing a directory as a file browser, using websockets, relaying requests, rewriting headers, inspecting traffic, TLS and TCP tunnels and lots more. All or which is explained in the Documentation.

It's worth noting that Ngrok isn't the only option here, other options include: FRP, Inlets, Local Tunnel, TailScale, etc. Check out Awesome Tunneling for a list of alternatives.

⬆️ Back to Top

Custom Domain​

Using DNS​

For locally running services, a domain can be set up directly in the DNS records. This method is really quick and easy, and doesn't require you to purchase an actual domain. Just update your networks DNS resolver, to point your desired URL to the local IP where Dashy (or any other app) is running. For example, a line in your hosts file might look something like: 192.168.0.2 dashy.homelab.local.

If you're using Pi-Hole, a similar thing can be done in the /etc/dnsmasq.d/03-custom-dns.conf file, add a line like: address=/dashy.example.com/192.168.2.0 for each of your services.

If you're running OPNSense/ PfSense, then this can be done through the UI with Unbound, it's explained nicely in this article, by Dustin Casto.

Using NGINX​

If you're using NGINX, then you can use your own domain name, with a config similar to the below example.

upstream dashy {
  server 127.0.0.1:8080;
}

server {
  listen         443 ssl;
  server_name    dashy.mydomain.com;

  # Setup SSL
  ssl_certificate             /var/www/mydomain/sslcert.pem;
  ssl_certificate_key         /var/www/mydomain/sslkey.pem;
  ssl_protocols               TLSv1.2 TLSv1.3;
  ssl_ciphers                 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
  ssl_session_timeout         5m;
  ssl_prefer_server_ciphers   on;

  location / {
    proxy_pass                http://dashy;
    proxy_redirect            off;
    proxy_buffering           off;
    proxy_set_header          host              $host;
    proxy_set_header          X-Real-IP         $remote_addr;
    proxy_set_header          X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_next_upstream       error timeout     invalid_header http_500 http_502 http_503 http_504;
  }
}

Similarly, a basic Caddyfile might look like:

dashy.example.com {
    reverse_proxy localhost:8080
}

For more info, this guide on Setting up Domains with NGINX Proxy Manager and CloudFlare may be useful.

⬆️ Back to Top

Verifying Releases​

Everything Dashy publishes can be verified, so you can check that what you're running is what our CI actually built.

Docker images: Every image pushed to GHCR has a signed SBOM (software bill of materials) and build provenance attestation attached. Verify with the GitHub CLI:

gh attestation verify oci://ghcr.io/lissy93/dashy:latest --repo lissy93/dashy

GitHub releases (non-Docker): Each release includes a pre-built tarball, along with a SHA256 checksum and its own provenance attestation. To check your download:

sha256sum -c dashy-<version>.tar.gz.sha256
gh attestation verify dashy-<version>.tar.gz --repo lissy93/dashy

If verification passes, the artifact was built by our GitHub Actions workflow, from the Dashy repo, and hasn't been tampered with since.

To pull the SBOM and see exactly what's inside an image, use cosign: cosign download sbom ghcr.io/lissy93/dashy:latest

⬆️ Back to Top

Container Security​

Keep Docker Up-To-Date​

To prevent known container escape vulnerabilities, which typically end in escalating to root/administrator privileges, patching Docker Engine is crucial. For more info, see the Docker Installation Docs.

Set Resource Quotas​

Docker enables you to limit resource consumption (CPU, memory, disk) on a per-container basis. This not only enhances system performance, but also prevents a compromised container from consuming a large amount of resources, in order to disrupt service or perform malicious activities. To learn more, see the Resource Constraints Docs

For example, to run Dashy with max of 1GB ram, and max of 50% of 1 CP core: docker run -d -p 8080:8080 --cpus=".5" --memory="1024m" lissy93/dashy:latest

Don't Run as Root​

Running Docker commands with sudo gives the container more host-level access than it needs. You should run Docker as a non-root host user instead.

If you're facing permission issues on Debian-based systems when running Docker commands without sudo, you may need to add your user to the Docker group. First create the group: sudo groupadd docker, then add your (non-root) user: sudo usermod βˆ’aG docker [my-username], finally newgrp docker to refresh.

Specify a User​

For containers in general, running as an unprivileged user is one of the best ways to prevent privilege escalation attacks. Dashy already does this: the image runs as the non-root node user (uid/gid 1000) out of the box, so there's nothing extra to set up.

If your host user isn't uid 1000, you can run the container as your own user instead, with the --user param, using the user ID (UID) from id -u and group ID (GID) from id -g:

docker run --user $(id -u):$(id -g) -p 8080:8080 lissy93/dashy

Or with Docker Compose, using an environmental variable:

services:
  dashy:
    image: lissy93/dashy
    user: ${CURRENT_UID}
    ports: [ 4000:8080 ]

And then to set the variable, and start the container, run: CURRENT_UID=$(id -u):$(id -g) docker-compose up

Whichever user the container runs as, it needs to own your mounted user-data directory for config saves from the UI to work. See File Ownership and Permissions for details.

Limit capabilities​

Docker containers run with a subset of Linux Kernal's Capabilities by default. It's good practice to drop privilege permissions that are not needed for any given container.

With Docker run, you can use the --cap-drop flag to remove capabilities, you can also use --cap-drop=all and then define just the required permissions using the --cap-add option. For a list of available capabilities, see the Privilege Capabilities Docs.

Note that dropping privileges and capabilities on runtime is not fool-proof, and often any leftover privileges can be used to re-escalate, see POS36-C.

Dashy runs as a non-root user on an unprivileged port, so it doesn't need any capabilities at all. The one exception is NET_RAW, which is only needed if you've enabled ICMP ping checks (pingCheckEnabled).

Here's an example using docker-compose, dropping everything except what's needed for ping checks (leave out cap_add entirely if you don't use them):

services:
  dashy:
    image: lissy93/dashy
    ports: [ 4000:8080 ]
    cap_drop:
    - ALL
    cap_add:
    - NET_RAW

Prevent new Privileges being Added​

To prevent processes inside the container from getting additional privileges, pass in the --security-opt=no-new-privileges:true option to the Docker run command (see docs).

Run Command: docker run --security-opt=no-new-privileges:true -p 8080:8080 lissy93/dashy

Docker Compose

security_opt:
- no-new-privileges:true

Kubernetes​

The same hardening applies on Kubernetes, via a securityContext on the container. The image sets a numeric user, so runAsNonRoot works without overrides, and since Dashy only ever writes to user-data, the root filesystem can be read-only too.

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: [ALL]
  seccompProfile:
    type: RuntimeDefault

If you use ping checks, add NET_RAW back under capabilities.add, and set the pod-level sysctl net.ipv4.ping_group_range to "0 2147483647" (it's on Kubernetes' safe list) so ping can work without privilege escalation.

Disable Inter-Container Communication​

By default Docker containers can talk to each other (using docker0 bridged network). If you don't need this capability, then it should be disabled. This is a daemon-level setting: add "icc": false to /etc/docker/daemon.json and restart Docker. Docker Compose sidesteps this by giving each project its own network. You can learn more about how to facilitate secure communication between containers in the Compose Networking docs.

Don't Expose the Docker Daemon Socket​

Docker socket /var/run/docker.sock is the UNIX socket that Docker is listening to. This is the primary entry point for the Docker API. The owner of this socket is root. Giving someone access to it is equivalent to giving unrestricted root access to your host.

You should not enable TCP Docker daemon socket (-H tcp://0.0.0.0:XXX), as doing so exposes un-encrypted and unauthenticated direct access to the Docker daemon, and if the host is connected to the internet, the daemon on your computer can be used by anyone from the public internet- which is bad. If you need TCP, you should see the docs to understand how to do this more securely. Similarly, never expose /var/run/docker.sock to other containers as a volume, as it can be exploited.

Use Read-Only Volumes​

You can specify that a volume should be read-only by appending :ro to the -v switch. If you don't need the in-app config editor, mount your user-data read-only:

docker run -d \
  -p 8080:8080 \
  -v ~/dashy-data:/app/user-data:ro \
  lissy93/dashy:latest

If you do want config changes from the UI to persist back to disk, leave the mount writable. You can also go further and use --read-only (or read_only: true in compose) to make the whole container filesystem read-only. Dashy only ever writes to user-data, so as long as that's a writable mount, saves from the UI keep working.

Set the Logging Level​

Logging is important, as it enables you to review events in the future, and in the case of a compromise this will let get an idea of what may have happened. The Docker daemon's default log level is info, and this is also the recommendation. It's set with "log-level": "info" in /etc/docker/daemon.json, or --log-level when starting dockerd.

Verify Image before Pulling​

Only use trusted images, from verified/ official sources. If an app is open source, it is more likely to be safe, as anyone can verify the code. There are also tools available for scanning containers.

Unless otherwise configured, containers can communicate among each other, so running one bad image may lead to other areas of your setup being compromised. Docker images typically contain both original code, as well as up-stream packages, and even if that image has come from a trusted source, the up-stream packages it includes may not have.

Every Dashy image is published with signed build provenance and an SBOM, so you can confirm it was genuinely built by our CI before you run it. See Verifying Releases.

Specify the Tag​

Using fixed tags (as opposed to :latest) will ensure immutability, meaning the image will not change between pulls. Dashy publishes latest, a major tag (4.x), a minor tag (4.7) and exact versions (4.7.5), so you can choose how tightly to pin. Note that Dashy is actively developed, with fixes and improvements merged most weeks, so it's up to you whether you'd prefer a stable and reproducible environment, or the latest features and enhancements.

Container Security Scanning​

It's helpful to be aware of any potential security issues in any of the Docker images you are using. You can run a quick scan on any image to output known vulnerabilities using Docker Scout, e.g: docker scout cves lissy93/dashy:latest.

A similar product is Trivy, which is free an open source. First install it (with your package manager), then to scan an image, just run: trivy image lissy93/dashy:latest

For larger systems, RedHat Clair is an app for parsing image contents and reporting on any found vulnerabilities. You run it locally in a container, and configure it with YAML. It can be integrated with Red Hat Quay, to show results on a dashboard. Most of these use static analysis to find potential issues, and scan included packages for any known security vulnerabilities.

Registry Security​

Although over-kill for most users, you could run your own registry locally which would give you ultimate control over all images, see the Deploying a Registry Docs for more info. Another option is Harbor, an open source registry with built-in vulnerability scanning and image signing.

Security Modules​

Docker supports several modules that let you write your own security profiles.

AppArmoris a kernel module that proactively protects the operating system and applications from external or internal threats, by enabling you to restrict programs' capabilities with per-program profiles. You can specify either a security policy by name, or by file path with the apparmor flag in docker run. Learn more about writing profiles, here.

Seccomp (Secure Computing Mode) is a sandboxing facility in the Linux kernel that acts like a firewall for system calls (syscalls). It uses Berkeley Packet Filter (BPF) rules to filter syscalls and control how they are handled. These filters can significantly limit a containers access to the Docker Host's Linux kernel - especially for simple containers/applications. It requires a Linux-based Docker host, with secomp enabled, and you can check for this by running docker info | grep seccomp. A great resource for learning more about this is DockerLabs.

⬆️ Back to Top

Web Server Configuration​

The following section only applies if you are not using Docker, and would like to use your own web server

Dashy ships with a pre-configured Node.js server, in server.js which serves up the contents of the ./dist directory on a given port. You can start the server by running node server. Note that the app must have been built (run yarn build), and you need Node.js installed.

If you wish to run Dashy from a sub page (e.g. example.com/dashy), see this troubleshooting section.

The built frontend is just static files, so it can be served with whatever server you like. The following section outlines how you can configure a web server.

Note that if you choose not to use server.js to serve up the app, you will lose access to the following features:

  • Writing config file to disk from the UI (and the automatic config backups)
  • Website status indicators, and ping checks
  • The CORS proxy used by widgets
  • Server-side authentication, the REST API and the /healthz endpoint

Example Configs

NGINX​

Create a new file in /etc/nginx/sites-enabled/dashy

server {
	listen 8080;
	listen [::]:8080;

	root /var/www/dashy/html;
	index index.html;

	server_name your-domain.com www.your-domain.com;

	location / {
		try_files $uri $uri/ =404;
	}
}

To use HTML5 history mode (the default - controlled via the VITE_APP_ROUTING_MODE build-time env var), replace the inside of the location block with: try_files $uri $uri/ /index.html;.

Then upload the build contents of Dashy's dist directory to that location. For example: scp -r ./dist/* [username]@[server_ip]:/var/www/dashy/html

Apache​

Copy Dashy's dist folder to your apache server, sudo cp -r ./dashy/dist /var/www/html/dashy.

In your Apache config, /etc/apche2/apache2.conf add:

<Directory /var/www/html>
	Options Indexes FollowSymLinks
	AllowOverride All
	Require all granted
</Directory>

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.html$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.html [L]
</IfModule>

Add a .htaccess file within /var/www/html/dashy/.htaccess, and add:

Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.html [QSA,L]

Then restart Apache, with sudo systemctl restart apache2

Caddy​

Caddy v2

try_files {path} /

Caddy v1

rewrite {
  regexp .*
  to {path} /
}

Firebase Hosting​

Create a file names firebase.json, and populate it with something similar to:

{
  "hosting": {
    "public": "dist",
    "rewrites": [
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

cPanel​

  1. Login to your WHM
  2. Open 'Feature Manager' on the left sidebar
  3. Under 'Manage feature list', click 'Edit'
  4. Find 'Application manager' in the list, enable it and hit 'Save'
  5. Log into your users cPanel account, and under 'Software' find 'Application Manager'
  6. Click 'Register Application', fill in the form using the path that Dashy is located, and choose a domain, and hit 'Save'
  7. The application should now show up in the list, click 'Ensure dependencies', and move the toggle switch to 'Enabled'
  8. If you need to change the port, click 'Add environmental variable', give it the name 'PORT', choose a port number and press 'Save'.
  9. Dashy should now be running at your selected path an on a given port

⬆️ Back to Top

Running a Modified Version of the App​

If you'd like to make any code changes to the app, and deploy your modified version, this section briefly explains how.

The first step is to fork the project on GitHub, and clone it to your local system. Next, install the dependencies (yarn), and start the development server (yarn dev) and visit localhost:8080 in your browser. You can then make changes to the codebase, and see the live app update in real-time. Once you've finished, running yarn build will build the app for production, and output the assets into ./dist which can then be deployed using a web server, CDN or the built-in Node server with yarn start. For more info on all of this, take a look at the Developing Docs. To build your own Docker container from the modified app, see Building your Own Container

⬆️ Back to Top

Building your Own Container​

Similar to above, you'll first need to fork and clone Dashy to your local system, and then install dependencies.

Then, either use Dashy's default Dockerfile as is, or modify it according to your needs. Note that the image runs as a non-root user, so if you add RUN steps that install packages or write anywhere outside user-data, switch to USER root first and back to USER 1000:1000 at the end.

To build and deploy locally, first build the app with: docker build -t dashy ., and then start the app with docker run -p 8080:8080 --name my-dashboard dashy. Or modify the docker-compose.yml file, replacing image: lissy93/dashy with build: . and run docker compose up.

Your container should now be running, and will appear in the list when you run docker container ls –a. If you'd like to enter the container, run docker exec -it [container-id] /bin/ash.

You may wish to upload your image to a container registry for easier access. Note that if you choose to do this on a public registry, please name your container something other than just 'dashy', to avoid confusion with the official image. You can push your build image, by running: docker push ghcr.io/OWNER/IMAGE_NAME:latest. You will first need to authenticate, this can be done by running echo $CR_PAT | docker login ghcr.io -u USERNAME --password-stdin, where CR_PAT is an environmental variable containing a token generated from your GitHub account. For more info, see the Container Registry Docs.

⬆️ Back to Top