A modern, fully static, fast, secure fully proxied, highly customizable application dashboard with integrations for over 100 services and translations into multiple languages. Easily configured via YAML files or through docker label discovery.
Homepage uses YAML for configuration, YAML stands for \"YAML Ain't Markup Language.\". It's a human-readable data serialization format that's a superset of JSON. Great for config files, easy to read and write. Supports complex data types like lists and objects. Indentation matters. If you already use Docker Compose, you already use YAML.
Here are some tips when writing YAML:
Use Indentation Carefully: YAML relies on indentation, not brackets.
Avoid Tabs: Stick to spaces for indentation to avoid parsing errors. 2 spaces are common.
Quote Strings: Use single or double quotes for strings with special characters, this is especially important for API keys.
Key-Value Syntax: Use key: value format. Colon must be followed by a space.
Validate: Always validate your YAML with a linter before deploying.
You can find tons of online YAML validators, here's one: https://codebeautify.org/yaml-validator, heres another: https://jsonformatter.org/yaml-validator.
Bookmarks are configured in the bookmarks.yaml file. They function much the same as Services, in how groups and lists work. They're just much simpler, smaller, and contain no extra features other than being a link out.
The design of homepage expects abbr to be 2 letters, but is not otherwise forced.
You can also use an icon for bookmarks similar to the options for service icons. If both icon and abbreviation are supplied, the icon takes precedence.
By default, the description will use the hostname of the link, but you can override it with a custom description.
---\n- Developer:\n - Github:\n - abbr: GH\n href: https://github.com/\n\n- Social:\n - Reddit:\n - icon: reddit.png\n href: https://reddit.com/\n description: The front page of the internet\n\n- Entertainment:\n - YouTube:\n - abbr: YT\n href: https://youtube.com/\n
As of version v0.6.30 homepage supports adding your own custom css & javascript. Please do so at your own risk.
To add custom css simply edit the custom.css file under your config directory, similarly for javascript you would edit custom.js. You can then target elements in homepage with various classes / ids to customize things to your liking.
You can also set a specific id for a service or bookmark to target with your custom css or javascript, e.g.
Since Docker supports connecting with TLS and client certificate authentication, you can include TLS details when connecting to the HTTP API. Further details of setting up Docker to accept TLS connections, and generation of the keys and certs can be found in the Docker documentation. The file entries are relative to the config directory (location of docker.yaml file).
Due to security concerns with exposing the docker socket directly, you can use a docker-socket-proxy container to expose the docker socket on a more restricted and secure API.
Here is an example docker-compose file that will expose the docker socket, and then connect to it from the homepage container:
dockerproxy:\n image: ghcr.io/tecnativa/docker-socket-proxy:latest\n container_name: dockerproxy\n environment:\n - CONTAINERS=1 # Allow access to viewing containers\n - SERVICES=1 # Allow access to viewing services (necessary when using Docker Swarm)\n - TASKS=1 # Allow access to viewing tasks (necessary when using Docker Swarm)\n - POST=0 # Disallow any POST operations (effectively read-only)\n ports:\n - 127.0.0.1:2375:2375\n volumes:\n - /var/run/docker.sock:/var/run/docker.sock:ro # Mounted as read-only\n restart: unless-stopped\n\nhomepage:\n image: ghcr.io/gethomepage/homepage:latest\n container_name: homepage\n volumes:\n - /path/to/config:/app/config\n ports:\n - 3000:3000\n restart: unless-stopped\n
Then, inside of your docker.yaml settings file, you'd configure the docker instance like so:
Once you've configured your docker instances, you can then apply them to your services, to get stats and status reporting shown.
Inside of the service you'd like to connect to docker:
- Emby:\n icon: emby.png\n href: \"http://emby.home/\"\n description: Media server\n server: my-docker # The docker server that was configured\n container: emby # The name of the container you'd like to connect\n
"},{"location":"configs/docker/#automatic-service-discovery","title":"Automatic Service Discovery","text":"
Homepage features automatic service discovery for containers with the proper labels attached, all configuration options can be applied using dot notation, beginning with homepage.
Below is an example of the same service entry shown above, as docker labels.
When your Docker instance has been properly configured, this service will be automatically discovered and added to your Homepage. You do not need to specify the server or container values, as they will be automatically inferred.
Docker swarm is supported and Docker services are specified with the same server and container notation. To enable swarm support you will need to include a swarm setting in your docker.yaml, e.g.
For the automatic service discovery to discover all services it is important that homepage should be deployed on a manager node. Set deploy requirements to the master node in your stack yaml config, e.g.
In order to detect every service within the Docker swarm it is necessary that service labels should be used and not container labels. Specify the homepage labels as:
Once the Kubernetes connection is configured, individual services can be configured to pull statistics. Only CPU and Memory are currently supported.
Inside of the service you'd like to connect to a pod:
- Emby:\n icon: emby.png\n href: \"http://emby.home/\"\n description: Media server\n namespace: media # The kubernetes namespace the app resides in\n app: emby # The name of the deployed app\n
The app field is used to create a label selector, in this example case it would match pods with the label: app.kubernetes.io/name=emby.
Sometimes this is insufficient for complex or atypical application deployments. In these cases, the pod-selector field can be used. Any field selector can be used with it, so it allows for some very powerful selection capabilities.
For instance, it can be utilized to roll multiple underlying deployments under one application to see a high-level aggregate:
A blank string as a pod-selector does not deactivate it, but will actually select all pods in the namespace. This is a useful way to capture the resource usage of a complex application siloed to a single namespace, like Longhorn.
"},{"location":"configs/kubernetes/#automatic-service-discovery","title":"Automatic Service Discovery","text":"
Homepage features automatic service discovery by Ingress annotations. All configuration options can be applied using typical annotation syntax, beginning with gethomepage.dev/.
When the Kubernetes cluster connection has been properly configured, this service will be automatically discovered and added to your Homepage. You do not need to specify the namespace or app values, as they will be automatically inferred.
If you are using multiple instances of homepage, an instance annotation can be specified to limit services to a specific instance. If no instance is provided, the service will be visible on all instances.
Homepage can also read ingresses defined using the Traefik IngressRoute custom resource definition. Due to the complex nature of Traefik routing rules, it is required for the gethomepage.dev/href annotation to be set:
Similarly to Docker service discovery, there currently is no rigid ordering to discovered services and discovered services will be displayed above those specified in the services.yaml.
Each widget can optionally provide a list of which fields should be visible via the fields widget property. If no fields are specified, then all fields will be displayed. The fields property must be a valid YAML array of strings. As an example, here is the entry for Sonarr showing only a couple of fields.
In all cases a widget will work and display all fields without specifying the fields property.
- Group A:\n - Service A:\n href: http://localhost/\n\n - Service B:\n href: http://localhost/\n\n - Service C:\n href: http://localhost/\n\n- Group B:\n - Service D:\n href: http://localhost/\n
- Group A:\n - Service A:\n href: http://localhost/\n description: This is my service\n\n- Group B:\n - Service B:\n href: http://localhost/\n description: This is another service\n
Services may have an icon attached to them, you can use icons from Dashboard Icons automatically, by passing the name of the icon, with, or without .png or with .svg to use the svg version.
You can also specify prefixed icons from Material Design Icons with mdi-XX or Simple Icons with si-XX.
You can specify a custom color by adding a hex color code as suffix e.g. mdi-XX-#f0d453 or si-XX-#a712a2.
To use a remote icon, use the absolute URL (e.g. https://...).
To use a local icon, first create a Docker mount to /app/public/icons and then reference your icon as /icons/myicon.png. You will need to restart the container when adding new icons.
Warning
Material Design Icons for brands were deprecated and may be removed in the future. Using Simple Icons for brand icons will prevent any issues if / when the Material Design Icons are removed.
- Group A:\n - Sonarr:\n icon: sonarr.png\n href: http://sonarr.host/\n description: Series management\n\n- Group B:\n - Radarr:\n icon: radarr.png\n href: http://radarr.host/\n description: Movie management\n\n- Group C:\n - Service:\n icon: mdi-flask-outline\n href: http://service.host/\n description: My cool service\n
Services may have an optional ping property that allows you to monitor the availability of an external host. As of v0.8.0, the ping feature attempts to use a true (ICMP) ping command on the underlying host. Currently, only IPv4 is supported.
Services may have an optional siteMonitor property (formerly ping) that allows you to monitor the availability of a URL you chose and have the response time displayed. You do not need to set your monitor URL equal to your href or ping URL.
Note
The site monitor feature works by making an http HEAD request to the URL, and falls back to GET in case that fails. It will not, for example, login if the URL requires auth or is behind e.g. Authelia. In the case of a reverse proxy and/or auth this usually requires the use of an 'internal' URL to make the site monitor feature correctly display status.
Services may be connected to a Docker container, either running on the local machine, or a remote machine.
- Group A:\n - Service A:\n href: http://localhost/\n description: This is my service\n server: my-server\n container: my-container\n\n- Group B:\n - Service B:\n href: http://localhost/\n description: This is another service\n server: other-server\n container: other-container\n
Clicking on the status label of a service with Docker integration enabled will expand the container stats, where you can see CPU, Memory, and Network activity.
Note
This can also be controlled with showStats. See show docker stats for more information
The settings.yaml file allows you to define application level options. For changes made to this file to take effect, you will need to regenerate the static HTML, this can be done by clicking the refresh icon in the bottom right of the page.
You can specify filters to apply over your background image for blur, saturation and brightness as well as opacity to blend with the background color. The first three filter settings use tailwind CSS classes, see notes below regarding the options for each. You do not need to specify all options.
background:\n image: /images/background.png\n blur: sm # sm, \"\", md, xl... see https://tailwindcss.com/docs/backdrop-blur\n saturate: 50 # 0, 50, 100... see https://tailwindcss.com/docs/backdrop-saturate\n brightness: 50 # 0, 50, 75... see https://tailwindcss.com/docs/backdrop-brightness\n opacity: 50 # 0-100\n
You can apply a blur filter to the service & bookmark cards. Note this option is incompatible with the background blur, saturate and brightness filters.
cardBlur: sm # sm, \"\", md, etc... see https://tailwindcss.com/docs/backdrop-blur\n
If you'd like to use a custom favicon instead of the included one, you may provide a full URL to an image of your choice.
favicon: https://www.google.com/favicon.ico\n
Or you may pass the path to a local image relative to the /app/public directory. See Background Image for more detailed information on how to provide your own files.
Service groups and bookmark groups can be mixed in order, but should use different group names. If you do not specify any bookmark groups they will all show at the bottom of the page.
Using the same name for a service and bookmark group can cause unexpected behavior like a bookmark group being hidden
Groups will sort based on the order in the layout block. You can also mix in groups defined by docker labels, e.g.
The default style for icons (e.g. icon: mdi-XXXX) is a gradient, or you can specify that prefixed icons match your theme with a 'flat' style using the setting below. More information about prefixed icons can be found in options for service icons.
iconStyle: theme # optional, defaults to gradient\n
Version 0.6.30 introduced a tabbed view to layouts which can be optionally specified in the layout. Tabs is only active if you set the tab field on at least one layout group.
Tabs are sorted based on the order in the layout block. If a group has no tab specified (and tabs are set on other groups), services and bookmarks will be shown on all tabs.
Every tab can be accessed directly by visiting Homepage URL with #Group (name lowercase and URI-encoded) at the end of the URL.
For example, the following would create four tabs:
layout:\n ...\n Bookmark Group on First Tab:\n tab: First\n\n First Service Group:\n tab: First\n style: row\n columns: 4\n\n Second Service Group:\n tab: Second\n columns: 4\n\n Third Service Group:\n tab: Third\n style: row\n\n Bookmark Group on Fourth Tab:\n tab: Fourth\n\n Service Group on every Tab:\n style: row\n columns: 4\n
The providers section allows you to define shared API provider options and secrets. Currently this allows you to define your weather API keys in secret and is also the location of the Longhorn URL and credentials.
You can use the 'Quick Launch' feature to search services, perform a web search or open a URL. To use Quick Launch, just start typing while on your homepage (as long as the search widget doesn't have focus).
There are a few optional settings for the Quick Launch feature:
searchDescriptions: which lets you control whether item descriptions are included in searches. This is off by default. When enabled, results that match the item name will be placed above those that only match the description.
hideInternetSearch: disable automatically including the currently-selected web search (e.g. from the widget) as a Quick Launch option. This is false by default, enabling the feature.
showSearchSuggestions: shows search suggestions for the internet search. This value will be inherited from the search widget if it is not specified. If it is not specified there either, it will default to false.
hideVisitURL: disable detecting and offering an option to open URLs. This is false by default, enabling the feature.
By default the homepage logfile is written to the a logs subdirectory of the config folder. In order to customize this path, you can set the logpath setting. A logs folder will be created in that location where the logfile will be written.
logpath: /logfile/path\n
By default, logs are sent both to stdout and to a file at the path specified. This can be changed by setting the LOG_TARGETS environment variable to one of both (default), stdout or file.
You have a few options for deploying homepage, depending on your needs. We offer docker images for a majority of platforms. You can also install and run homepage from source if Docker is not your thing. It can even be installed on Kubernetes with Helm.
version: \"3.3\"\nservices:\n homepage:\n image: ghcr.io/gethomepage/homepage:latest\n container_name: homepage\n ports:\n - 3000:3000\n volumes:\n - /path/to/config:/app/config # Make sure your local config directory exists\n - /var/run/docker.sock:/var/run/docker.sock # (optional) For docker integrations\n
"},{"location":"installation/docker/#running-as-non-root","title":"Running as non-root","text":"
By default, the Homepage container runs as root. Homepage also supports running your container as non-root via the standard PUID and PGID environment variables. When using these variables, make sure that any volumes mounted in to the container have the correct ownership and permissions set.
Using the docker socket directly is not the recommended method of integration and requires either running homepage as root or that the user be part of the docker group
In the docker compose example below, the environment variables $PUID and $PGID are set in a .env file.
version: \"3.3\"\nservices:\n homepage:\n image: ghcr.io/gethomepage/homepage:latest\n container_name: homepage\n ports:\n - 3000:3000\n volumes:\n - /path/to/config:/app/config # Make sure your local config directory exists\n - /var/run/docker.sock:/var/run/docker.sock # (optional) For docker integrations, see alternative methods\n environment:\n PUID: $PUID\n PGID: $PGID\n
You can also include environment variables in your config files to protect sensitive information. Note:
Environment variables must start with HOMEPAGE_VAR_ or HOMEPAGE_FILE_
The value of env var HOMEPAGE_VAR_XXX will replace {{HOMEPAGE_VAR_XXX}} in any config
The value of env var HOMEPAGE_FILE_XXX must be a file path, the contents of which will be used to replace {{HOMEPAGE_FILE_XXX}} in any config
"},{"location":"installation/k8s/","title":"Kubernetes Installation","text":""},{"location":"installation/k8s/#install-with-helm","title":"Install with Helm","text":"
There is an unofficial helm chart that creates all the necessary manifests, including the service account and RBAC entities necessary for service discovery.
The helm chart allows for all the configurations to be inlined directly in your values.yaml:
config:\n bookmarks:\n - Developer:\n - Github:\n - abbr: GH\n href: https://github.com/\n services:\n - My First Group:\n - My First Service:\n href: http://localhost/\n description: Homepage is awesome\n\n - My Second Group:\n - My Second Service:\n href: http://localhost/\n description: Homepage is the best\n\n - My Third Group:\n - My Third Service:\n href: http://localhost/\n description: Homepage is \ud83d\ude0e\n widgets:\n # show the kubernetes widget, with the cluster summary and individual nodes\n - kubernetes:\n cluster:\n show: true\n cpu: true\n memory: true\n showLabel: true\n label: \"cluster\"\n nodes:\n show: true\n cpu: true\n memory: true\n showLabel: true\n - search:\n provider: duckduckgo\n target: _blank\n kubernetes:\n mode: cluster\n settings:\n\n# The service account is necessary to allow discovery of other services\nserviceAccount:\n create: true\n name: homepage\n\n# This enables the service account to access the necessary resources\nenableRbac: true\n\ningress:\n main:\n enabled: true\n annotations:\n # Example annotations to add Homepage to your Homepage!\n gethomepage.dev/enabled: \"true\"\n gethomepage.dev/name: \"Homepage\"\n gethomepage.dev/description: \"Dynamically Detected Homepage\"\n gethomepage.dev/group: \"Dynamic\"\n gethomepage.dev/icon: \"homepage.png\"\n hosts:\n - host: homepage.example.com\n paths:\n - path: /\n pathType: Prefix\n
"},{"location":"installation/k8s/#install-with-kubernetes-manifests","title":"Install with Kubernetes Manifests","text":"
If you don't want to use the unofficial Helm chart, you can also create your own Kubernetes manifest(s) and apply them with kubectl apply -f filename.yaml.
Here's a working example of the resources you need:
If you plan to deploy homepage with a replica count greater than 1, you may want to consider enabling sticky sessions on the homepage route. This will prevent unnecessary re-renders on page loads and window / tab focusing. The procedure for enabling sticky sessions depends on your Ingress controller. Below is an example using Traefik as the Ingress controller.
When you upload a new image into the /images folder, you will need to restart the container for it to show up in the WebUI. Please see the service icons for more information.
"},{"location":"more/","title":"More","text":"
Here you'll find resources and guides for Homepage, troubleshooting tips, and more.
Once dependencies have been installed you can lint your code with
pnpm lint\n
"},{"location":"more/development/#code-formatting-with-pre-commit-hooks","title":"Code formatting with pre-commit hooks","text":"
To ensure a consistent style and formatting across the project source, the project utilizes Git pre-commit hooks to perform some formatting and linting before a commit is allowed.
Once installed, hooks will run when you commit. If the formatting isn't quite right, the commit will be rejected and you'll need to look at the output and fix the issue. Most hooks will automatically format failing files, so all you need to do is git add those files again and retry your commit.
In general, homepage is meant to be a dashboard for 'self-hosted' services and we believe it is a small way we can help showcase this kind of software. While exceptions are made, mostly when there is no viable self-hosted / open-source alternative, we ask that any widgets, etc. are developed primarily for a self-hosted tool.
New features should be linked to an existing feature request with at least 10 'up-votes'. The purpose of this requirement is to avoid the addition (and maintenance) of features that might only benefit a small number of users.
If you have ideas for a larger feature, please open a discussion first.
Please note that though it is a requirement, a discussion with 10 'up-votes' in no way guarantees that a PR will be merged.
To ensure cohesiveness of various widgets, the following should be used as a guide for developing new widgets:
Please only submit widgets that have been requested and have at least 10 'up-votes'. The purpose of this requirement is to avoid the addition (and maintenance) of service widgets that might only benefit a small number of users.
Widgets should be only one row of blocks
Widgets should be no more than 4 blocks wide and generally conform to the styling / design choices of other widgets
Minimize the number of API calls
Avoid the use of custom proxy unless absolutely necessary
Widgets should be 'read-only', as in they should not make write changes using the relevant tool's API. Homepage widgets are designed to surface information, not to be a (usually worse) replacement for the tool itself.
As of v0.7.2 homepage migrated from benphelps/homepage to an \"organization\" repository located at gethomepage/homepage. The reason for this was to setup the project for longevity and allow for community maintenance.
Migrating your installation should be as simple as changing image: ghcr.io/benphelps/homepage:latest to image: ghcr.io/gethomepage/homepage:latest.
Homepage is developed in English, component contributions must be in English. All translations are community provided, so a huge thanks go out to all those who have helped out so far!
If you'd like to lend a hand in translating Homepage into more languages, or to improve existing translations, the process is very simple:
Create a free account at Crowdin
Visit the Homepage project
Select the language you'd like to translate
Start translating!
"},{"location":"more/translations/#adding-a-new-language","title":"Adding a new language","text":"
If you'd like to add a new language, please create a new Discussion on Crowdin, and we'll add it to the project.
"},{"location":"more/troubleshooting/","title":"Troubleshooting","text":""},{"location":"more/troubleshooting/#introducing-the-homepage-ai-bot","title":"Introducing the Homepage AI Bot","text":"
Thanks to the generous folks at Glime, Homepage is now equipped with a pretty clever AI-powered bot. The bot has full knowledge of our docs, GitHub issues and discussions and is great at answering specific questions about setting up your Homepage. To use the bot, just hit the 'Ask AI' button on any page in our docs, open a GitHub discussion or check out the #ai-support channel on Discord!
For API errors, clicking the \"API Error Information\" button in the widget will usually show some helpful information as to whether the issue is reaching the service host, an authentication issue, etc.
Check config/logs/homepage.log, on docker simply e.g. docker logs homepage. This may provide some insight into the reason for an error.
Check the browser error console, this can also sometimes provide useful information.
Consider setting the ENV variable LOG_LEVEL to debug.
All service widgets work essentially the same, that is, homepage makes a proxied call to an API made available by that service. The majority of the time widgets don't work it is a configuration issue. Of course, sometimes things do break. Some basic steps to try:
Ensure that you follow the rule mentioned on https://gethomepage.dev/latest/configs/service-widgets/. Unless otherwise noted, URLs should not end with a / or other API path. Each widget will handle the path on its own.. This is very important as including a trailing slash can result in an error.
Verify the homepage installation can connect to the IP address or host you are using for the widget url. This is most simply achieved by pinging the server from the homepage machine, in Docker this means from inside the container itself, e.g.:
docker exec homepage ping SERVICEIPORDOMAIN\n
If your homepage install (container) cannot reach the service then you need to figure out why, for example in Docker this can mean putting the two containers on the same network, checking firewall issues, etc.
If you have verified that homepage can in fact reach the service then you can also check the API output using e.g. curl, which is often helpful if you do need to file a bug report. Again, depending on your networking setup this may need to be run from inside the container as IP / hostname resolution can differ inside vs outside.
Note
curl is not installed in the base image by default but can be added inside the container with apk add curl.
The exact API endpoints and authentication vary of course, but in many cases instructions can be found by searching the web or if you feel comfortable looking at the homepage source code (e.g. src/widgets/{widget}/widget.js).
It is out of the scope of this to go into full detail about how to , but an example for PiHole would be:
If, after correctly adding and mapping your custom icons via the Icons instructions, you are still unable to see your icons please try recreating your container.
Service widgets are used to display the status of a service, often a web service or API. Services (and their widgets) are defined in your services.yaml file. Here's an example:
- Plex:\n icon: plex.png\n href: https://plex.my.host\n description: Watch movies and TV shows.\n server: localhost\n container: plex\n widget:\n type: tautulli\n url: http://172.16.1.1:8181\n key: aabbccddeeffgghhiijjkkllmmnnoo\n
Info widgets are used to display information in the header, often about your system or environment. Info widgets are defined your widgets.yaml file. Here's an example:
This allows you to display the date and/or time, can be heavily configured using Intl.DateTimeFormat.
Formatting is locale aware and will present your date in the regional format you expect, for example, 9/16/22, 3:03 PM for locale en and 16.09.22, 15:03 for de. You can also specify a locale just for the datetime widget with the locale option (see below).
The Glances widget allows you to monitor the resources (CPU, memory, storage, temp & uptime) of host or another machine, and is designed to match the resources info widget. You can have multiple instances by adding another configuration block. The cputemp, uptime & disk states require separate API calls and thus are not enabled by default. Glances needs to be running in \"web server\" mode to enable the API, see the glances docs.
- glances:\n url: http://host.or.ip:port\n username: user # optional if auth enabled in Glances\n password: pass # optional if auth enabled in Glances\n version: 4 # required only if running glances v4 or higher, defaults to 3\n cpu: true # optional, enabled by default, disable by setting to false\n mem: true # optional, enabled by default, disable by setting to false\n cputemp: true # disabled by default\n uptime: true # disabled by default\n disk: / # disabled by default, use mount point of disk(s) in glances. Can also be a list (see below)\n diskUnits: bytes # optional, bytes (default) or bbytes. Only applies to disk\n expanded: true # show the expanded view\n label: MyMachine # optional\n
This is very similar to the Resources widget, but provides resource information about a Kubernetes cluster.
It provides CPU and Memory usage, by node and/or at the cluster level.
- kubernetes:\n cluster:\n # Shows cluster-wide statistics\n show: true\n # Shows the aggregate CPU stats\n cpu: true\n # Shows the aggregate memory stats\n memory: true\n # Shows a custom label\n showLabel: true\n label: \"cluster\"\n nodes:\n # Shows node-specific statistics\n show: true\n # Shows the CPU for each node\n cpu: true\n # Shows the memory for each node\n memory: true\n # Shows the label, which is always the node name\n showLabel: true\n
The Longhorn widget pulls storage utilization metrics from the Longhorn storage driver on Kubernetes. It is designed to appear similar to the Resource widget's disk representation.
The exact metrics should be very similar to what is seen on the Longhorn dashboard itself.
It can show the aggregate metrics and/or the individual node metrics.
- longhorn:\n # Show the expanded view\n expanded: true\n # Shows a node representing the aggregate values\n total: true\n # Shows the node names as labels\n labels: true\n # Show the nodes\n nodes: true\n # An explicit list of nodes to show. All are shown by default if \"nodes\" is true\n include:\n - node1\n - node2\n
The Longhorn URL and credentials are stored in the providers section of the settings.yaml. e.g.:
The free tier \"One Call API\" is all that's required, you will need to subscribe and grab your API key.
- openweathermap:\n label: Kyiv #optional\n latitude: 50.449684\n longitude: 30.525026\n units: metric # or imperial\n provider: openweathermap\n apiKey: youropenweathermapkey # required only if not using provider, this reveals api key in requests\n cache: 5 # Time in minutes to cache API responses, to stay within limits\n format: # optional, Intl.NumberFormat options\n maximumFractionDigits: 1\n
You can optionally not pass a latitude and longitude and the widget will use your current location (requires a secure context, eg. HTTPS).
You can include all or some of the available resources. If you do not want to see that resource, simply pass false.
The disk path is the path reported by df (Mounted On), or the mount point of the disk.
The cpu and memory resource information are the container's usage while glances displays statistics for the host machine on which it is installed.
Note: unfortunately, the package used for getting CPU temp (systeminformation) is not compatible with some setups and will not report any value(s) for CPU temp.
Any disk you wish to access must be mounted to your container as a volume.
- resources:\n cpu: true\n memory: true\n disk: /disk/mount/path\n cputemp: true\n tempmin: 0 # optional, minimum cpu temp\n tempmax: 100 # optional, maximum cpu temp\n uptime: true\n units: imperial # only used by cpu temp\n refresh: 3000 # optional, in ms\n diskUnits: bytes # optional, bytes (default) or bbytes. Only applies to disk\n
You can also pass a label option, which allows you to group resources under named sections,
You can additionally supply an optional expanded property set to true in order to show additional details about the resources. By default the expanded property is set to false when not supplied.
You can add a search bar to your top widget area that can search using Google, Duckduckgo, Bing, Baidu, Brave or any other custom provider that supports the basic ?q= search query param.
- search:\n provider: google # google, duckduckgo, bing, baidu, brave or custom\n focus: true # Optional, will set focus to the search bar on page load\n showSearchSuggestions: true # Optional, will show search suggestions. Defaults to false\n target: _blank # One of _self, _blank, _parent or _top\n
The first entry of the array contains the search query, the second one is an array of the suggestions. In the example above, the search query was home.
You can display general connectivity status from your Unifi (Network) Controller. When authenticating you will want to use a local account that has at least read privileges.
An optional 'site' parameter can be supplied, if it is not the widget will use the default site for the controller.
Note: If you enter e.g. incorrect credentials and receive an \"API Error\", you may need to recreate the container to clear the cache.
- unifi_console:\n url: https://unifi.host.or.ip:port\n username: user\n password: pass\n site: Site Name # optional\n
Note: this widget is considered 'deprecated' since there is no longer a free Weather API tier for new members. See the openmeteo or openweathermap widgets for alternatives.
The free tier is all that's required, you will need to register and grab your API key.
- weatherapi:\n label: Kyiv # optional\n latitude: 50.449684\n longitude: 30.525026\n units: metric # or imperial\n apiKey: yourweatherapikey\n cache: 5 # Time in minutes to cache API responses, to stay within limits\n format: # optional, Intl.NumberFormat options\n maximumFractionDigits: 1\n
You can optionally not pass a latitude and longitude and the widget will use your current location (requires a secure context, eg. HTTPS).
This widget reads the number of active users in the system, as well as logins for the last 24 hours.
You will need to generate an API token for an existing user under Admin Portal > Directory > Tokens & App passwords. Make sure to set Intent to \"API Token\".
The account you made the API token for also needs the following Assigned global permissions in Authentik:
Pipelines: checks if the relevant pipeline is running or not, and if not, reports the last status. Allowed fields: [\"result\", \"status\"].
Pull Requests: returns the amount of open PRs, the amount of the PRs you have open, and how many PRs that you open are marked as 'Approved' by at least 1 person and not yet completed. Allowed fields: [\"totalPrs\", \"myPrs\", \"approved\"].
You will need to generate a personal access token for an existing user, see the azure documentation
widget:\n type: azuredevops\n organization: myOrganization\n project: myProject\n definitionId: pipelineDefinitionId # required for pipelines\n branchName: branchName # optional for pipelines, leave empty for all\n userEmail: email # required for pull requests\n repositoryId: prRepositoryId # required for pull requests\n key: personalaccesstoken\n
This widget shows monthly calendar, with optional integrations to show events from supported widgets.
widget:\n type: calendar\n firstDayInWeek: sunday # optional - defaults to monday\n view: monthly # optional - possible values monthly, agenda\n maxEvents: 10 # optional - defaults to 10\n showTime: true # optional - show time for event happening today - defaults to false\n timezone: America/Los_Angeles # optional and only when timezone is not detected properly (slightly slower performance) - force timezone for ical events (if it's the same - no change, if missing or different in ical - will be converted to this timezone)\n integrations: # optional\n - type: sonarr # active widget type that is currently enabled on homepage - possible values: radarr, sonarr, lidarr, readarr, ical\n service_group: Media # group name where widget exists\n service_name: Sonarr # service name for that widget\n color: teal # optional - defaults to pre-defined color for the service (teal for sonarr)\n params: # optional - additional params for the service\n unmonitored: true # optional - defaults to false, used with *arr stack\n - type: ical # Show calendar events from another service\n url: https://domain.url/with/link/to.ics # URL with calendar events\n name: My Events # required - name for these calendar events\n color: zinc # optional - defaults to pre-defined color for the service (zinc for ical)\n params: # optional - additional params for the service\n showName: true # optional - show name before event title in event line - defaults to false\n
This view shows only list of events from configured integrations
widget:\n type: calendar\n view: agenda\n maxEvents: 10 # optional - defaults to 10\n showTime: true # optional - show time for event happening today - defaults to false\n previousDays: 3 # optional - shows events since three days ago - defaults to 0\n integrations: # same as in Monthly view example\n
This custom integration allows you to show events from any calendar that supports iCal format, for example, Google Calendar (go to Settings, select specific calendar, go to Integrate calendar, copy URL from Public Address in iCal format).
As of v0.6.10 this widget no longer accepts a Cloudflare global API key (or account email) due to security concerns. Instead, you should setup an API token which only requires the permissions Account.Cloudflare Tunnel:Read.
Allowed fields: [\"status\", \"origin_ip\"].
widget:\n type: cloudflared\n accountid: accountid # from zero trust dashboard url e.g. https://one.dash.cloudflare.com/<accountid>/home/quick-start\n tunnelid: tunnelid # found in tunnels dashboard under the tunnel name\n key: cloudflareapitoken # api token with `Account.Cloudflare Tunnel:Read` https://dash.cloudflare.com/profile/api-tokens\n
See the crowdsec docs for information about registering a machine, in most instances you can use the default credentials (/etc/crowdsec/local_api_credentials.yaml).
This widget can show information from custom self-hosted or third party API.
Fields need to be defined in the mappings section YAML object to correlate with the value in the APIs JSON object. Final field definition needs to be the key with the desired value information.
widget:\n type: customapi\n url: http://custom.api.host.or.ip:port/path/to/exact/api/endpoint\n refreshInterval: 10000 # optional - in milliseconds, defaults to 10s\n username: username # auth - optional\n password: password # auth - optional\n method: GET # optional, e.g. POST\n headers: # optional, must be object, see below\n requestBody: # optional, can be string or object, see below\n display: # optional, default to block, see below\n mappings:\n - field: key # needs to be YAML string or object\n label: Field 1\n format: text # optional - defaults to text\n - field: # needs to be YAML string or object\n path:\n to: key2\n format: number # optional - defaults to text\n label: Field 2\n - field: # needs to be YAML string or object\n path:\n to:\n another: key3\n label: Field 3\n format: percent # optional - defaults to text\n - field: key # needs to be YAML string or object\n label: Field 4\n format: date # optional - defaults to text\n locale: nl # optional\n dateStyle: long # optional - defaults to \"long\". Allowed values: `[\"full\", \"long\", \"medium\", \"short\"]`.\n timeStyle: medium # optional - Allowed values: `[\"full\", \"long\", \"medium\", \"short\"]`.\n - field: key # needs to be YAML string or object\n label: Field 5\n format: relativeDate # optional - defaults to text\n locale: nl # optional\n style: short # optional - defaults to \"long\". Allowed values: `[\"long\", \"short\", \"narrow\"]`.\n numeric: auto # optional - defaults to \"always\". Allowed values `[\"always\", \"auto\"]`.\n - field: key\n label: Field 6\n format: text\n additionalField: # optional\n field:\n hourly:\n time: other key\n color: theme # optional - defaults to \"\". Allowed values: `[\"theme\", \"adaptive\", \"black\", \"white\"]`.\n format: date # optional\n
Supported formats for the values are text, number, float, percent, bytes, bitrate, date and relativeDate.
The dateStyle and timeStyle options of the date format are passed directly to Intl.DateTimeFormat and the style and numeric options of relativeDate are passed to Intl.RelativeTimeFormat.
You can manipulate data with the following tools remap, scale, prefix and suffix, for example:
- field: key4\n label: Field 4\n format: text\n remap:\n - value: 0\n to: None\n - value: 1\n to: Connected\n - any: true # will map all other values\n to: Unknown\n- field: key5\n label: Power\n format: float\n scale: 0.001 # can be number or string e.g. 1/16\n suffix: \"kW\"\n- field: key6\n label: Price\n format: float\n prefix: \"$\"\n
You can change the default block view to a list view by setting the display option to list.
The list view can optionally display an additional field next to the primary field.
additionalField: Similar to field, but only used in list view. Displays additional information for the mapping object on the right.
field: Defined the same way as other custom api widget fields.
color: Allowed options: \"theme\", \"adaptive\", \"black\", \"white\". The option adaptive will apply a color using the value of the additionalField, green for positive numbers, red for negative numbers.
- field: key\n label: Field\n format: text\n remap:\n - value: 0\n to: None\n - value: 1\n to: Connected\n - any: true # will map all other values\n to: Unknown\n additionalField:\n field:\n hourly:\n time: key\n color: theme\n format: date\n
"},{"location":"widgets/services/diskstation/","title":"Synology Disk Station","text":"
Learn more about Synology Disk Station.
Note: the widget is not compatible with 2FA.
An optional 'volume' parameter can be supplied to specify which volume's free space to display when more than one volume exists. The value of the parameter must be in form of volume_N, e.g. to display free space for volume2, volume_2 should be set as 'volume' value. If omitted, first returned volume's free space will be shown (not guaranteed to be volume1).
To access these system metrics you need to connect to the DiskStation (DSM) with an account that is a member of the default Administrators group. That is because these metrics are requested from the API's SYNO.Core.System part that is only available to admin users. In order to keep the security impact as small as possible we can set the account in DSM up to limit the user's permissions inside the Synology system. In DSM 7.x, for instance, follow these steps:
Create a new user, i.e. remote_stats.
Set up a strong password for the new user
Under the User Groups tab of the user config dialogue check the box for Administrators.
On the Permissions tab check the top box for No Access, effectively prohibiting the user from accessing anything in the shared folders.
Under Applications check the box next to Deny in the header to explicitly prohibit login to all applications.
Now only allow login to the DSM application, either by
unchecking Deny in the respective row, or (if inheriting permission doesn't work because of other group settings)
checking Allow for this app, or
checking By IP for this app to limit the source of login attempts to one or more IP addresses/subnets.
When the Preview column shows Allow in the DSM row, click Save.
Now configure the widget with the correct login information and test it.
If you encounter issues during testing:
Make sure to uncheck the option for automatic blocking due to invalid logins under Control Panel > Security > Protection.
If desired, this setting can be reactivated once the login is established working.
Login to your Synology DSM with the newly created account and accept terms and conditions.
You can create an API key from inside Emby at Settings > Advanced > Api Keys.
As of v0.6.11 the widget supports fields [\"movies\", \"series\", \"episodes\", \"songs\"]. These blocks are disabled by default but can be enabled with the enableBlocks option, and the \"Now Playing\" feature (enabled by default) can be disabled with the enableNowPlaying option.
widget:\n type: emby\n url: http://emby.host.or.ip\n key: apikeyapikeyapikeyapikeyapikey\n enableBlocks: true # optional, defaults to false\n enableNowPlaying: true # optional, defaults to true\n enableUser: true # optional, defaults to false\n showEpisodeNumber: true # optional, defaults to false\n expandOneStreamToTwoRows: false # optional, defaults to true\n
Show the number of ESPHome devices based on their state.
Allowed fields: [\"total\", \"online\", \"offline\", \"offline_alt\", \"unknown\"] (maximum of 4).
By default ESPHome will only mark devices as offline if their address cannot be pinged. If it has an invalid config or its name cannot be resolved (by DNS) its status will be marked as unknown. To group both offline and unknown devices together, users should use the offline_alt field instead. This sums all devices that are not online together.
Application access & UPnP must be activated on your device:
Home Network > Network > Network Settings > Access Settings in the Home Network\n[x] Allow access for applications\n[x] Transmit status information over UPnP\n
Credentials are not needed and, as such, you may want to consider using http instead of https as those requests are significantly faster.
Allowed fields (limited to a max of 4): [\"connectionStatus\", \"uptime\", \"maxDown\", \"maxUp\", \"down\", \"up\", \"received\", \"sent\", \"externalIPAddress\"].
The Glances widget allows you to monitor the resources (cpu, memory, diskio, sensors & processes) of host or another machine. You can have multiple instances by adding another service block.
widget:\n type: glances\n url: http://glances.host.or.ip:port\n username: user # optional if auth enabled in Glances\n password: pass # optional if auth enabled in Glances\n version: 4 # required only if running glances v4 or higher, defaults to 3\n metric: cpu\n diskUnits: bytes # optional, bytes (default) or bbytes. Only applies to disk\n refreshInterval: 5000 # optional - in milliseconds, defaults to 1000 or more, depending on the metric\n pointsLimit: 15 # optional, defaults to 15\n
Please note, this widget does not need an href, icon or description on its parent service. To achieve the same effect as the examples above, see as an example:
The metric field in the configuration determines the type of system monitoring data to be displayed. Here are the supported metrics:
info: System information. Shows the system's hostname, OS, kernel version, CPU type, CPU usage, RAM usage and SWAP usage.
cpu: CPU usage. Shows how much of the system's computational resources are currently being used.
memory: Memory usage. Shows how much of the system's RAM is currently being used.
process: Top 5 processes based on CPU usage. Gives an overview of which processes are consuming the most resources.
network:<interface_name>: Network data usage for the specified interface. Replace <interface_name> with the name of your network interface, e.g., network:enp0s25, as specified in glances.
sensor:<sensor_id>: Temperature of the specified sensor, typically used to monitor CPU temperature. Replace <sensor_id> with the name of your sensor, e.g., sensor:Package id 0 as specified in glances.
disk:<disk_id>: Disk I/O data for the specified disk. Replace <disk_id> with the id of your disk, e.g., disk:sdb, as specified in glances.
gpu:<gpu_id>: GPU usage for the specified GPU. Replace <gpu_id> with the id of your GPU, e.g., gpu:0, as specified in glances.
fs:<mnt_point>: Disk usage for the specified mount point. Replace <mnt_point> with the path of your disk, e.g., /mnt/storage, as specified in glances.
Specify a single check by including the uuid field or show the total 'up' and 'down' for all checks by leaving off the uuid field.
To use the Health Checks widget, you first need to generate an API key.
In your project, go to project Settings on the navigation bar.
Click on API key (read-only) and then click Create.
Copy the API key that is generated for you.
Allowed fields: [\"status\", \"last_ping\"] for single checks, [\"up\", \"down\"] for total stats.
widget:\n type: healthchecks\n url: http://healthchecks.host.or.ip:port\n key: <YOUR_API_KEY>\n uuid: <CHECK_UUID> # optional, if not included total statistics for all checks is shown\n
Up to a maximum of four custom states and/or templates can be queried via the custom property like in the example below. The custom property will have no effect as long as the fields property is defined.
state will query the state of the specified entity_id
state labels and values can be user defined and may reference entity attributes in curly brackets
if no state label is defined it will default to \"{attributes.friendly_name}\"
if no state value is defined it will default to \"{state} {attributes.unit_of_measurement}\"
template will query the specified template, see Home Assistant Templating
The Homebridge API is actually provided by the Config UI X plugin that has been included with Homebridge for a while, still it is required to be installed for this widget to work.
You can create an API key from inside Jellyfin at Settings > Advanced > Api Keys.
As of v0.6.11 the widget supports fields [\"movies\", \"series\", \"episodes\", \"songs\"]. These blocks are disabled by default but can be enabled with the enableBlocks option, and the \"Now Playing\" feature (enabled by default) can be disabled with the enableNowPlaying option.
widget:\n type: jellyfin\n url: http://jellyfin.host.or.ip\n key: apikeyapikeyapikeyapikeyapikey\n enableBlocks: true # optional, defaults to false\n enableNowPlaying: true # optional, defaults to true\n enableUser: true # optional, defaults to false\n showEpisodeNumber: true # optional, defaults to false\n expandOneStreamToTwoRows: false # optional, defaults to true\n
Use the base URL of the Mastodon instance you'd like to pull stats for. Does not require authentication as the stats are part of the public API endpoints.
If your moonraker instance has an active authorization and your homepage ip isn't whitelisted you need to add your api key (Authorization Documentation).
Use username & password, or the NC-Token key. Information about the token can be found under Settings > System. If both are provided, NC-Token will be used.
This widget uses the same authentication method as your browser when logging in (HTTP Basic Auth), and is often referred to as the ControlUsername and ControlPassword inside of Nzbget documentation.
The method field determines the type of data to be displayed and is required. Supported methods:
services.getStatus: Shows status of running services. Allowed fields: [\"running\", \"stopped\", \"total\"]
smart.getListBg: Shows S.M.A.R.T. status from disks. Allowed fields: [\"passed\", \"failed\"]
downloader.getDownloadList: Displays the number of tasks from the Downloader plugin currently being downloaded and total. Allowed fields: [\"downloading\", \"total\"]
The API key & secret can be generated via the webui by creating a new user at System/Access/Users. Ensure \"Generate a scrambled password to prevent local database logins for this user\" is checked and then edit the effective privileges selecting only:
Diagnostics: System Activity
Status: Traffic Graph
Finally, create a new API key which will download an apikey.txt file with your key and secret in it. Use the values as the username and password fields, respectively, in your homepage config.
Use username & password, or the token key. Information about the token can be found in the Paperless-ngx API documentation. If both are provided, the token will be used.
This widget requires an additional tool, PeaNUT, as noted. Other projects exist to achieve similar results using a customapi widget, for example NUTCase.
This widget requires the installation of the pfsense-api which is a 3rd party package for pfSense routers.
Once pfSense API is installed, you can set the API to be read-only in System > API > Settings.
There are two currently supported authentication modes: 'Local Database' and 'API Token'. For 'Local Database', use username and password with the credentials of an admin user. For 'API Token', utilize the headers parameter with client_token and client_id obtained from pfSense as shown below. Do not use both headers and username / password.
The interface to monitor is defined by updating the wan parameter. It should be referenced as it is shown under Interfaces > Assignments in pfSense.
Load is returned instead of cpu utilization. This is a limitation in the pfSense API due to the complexity of this calculation. This may become available in future versions.
As of v2022.12 PiHole requires the use of an API key if an admin password is set. Older versions do not require any authentication even if the admin uses a password.
Note: by default the \"blocked\" and \"blocked_percent\" fields are merged e.g. \"1,234 (15%)\" but explicitly including the \"blocked_percent\" field will change them to display separately.
widget:\n type: pihole\n url: http://pi.hole.or.ip\n version: 6 # required if running v6 or higher, defaults to 5\n key: yourpiholeapikey # optional\n
The core Plex API is somewhat limited but basic info regarding library sizes and the number of active streams is supported. For more detailed info regarding active streams see the Plex Tautulli widget.
You'll need to make sure you have the correct environment set for the integration to work properly. From the Environments section inside of Portainer, click the one you'd like to connect to and observe the ID at the end of the URL (should be), something like #!/endpoints/1, here 1 is the value to set as the env value. In order to generate an API key, please follow the steps outlined here https://docs.portainer.io/api/access.
This widget shows the running and total counts of both QEMU VMs and LX Containers in the Proxmox cluster. It also shows the CPU and memory usage of the first node in the cluster.
You will need to generate an API Token for new or an existing user. Here is an example of how to do this for a new user.
Navigate to the Proxmox portal, click on Datacenter
Expand Permissions, click on Groups
Click the Create button
Name the group something informative, like api-ro-users
Click on the Permissions \"folder\"
Click Add -> Group Permission
Path: /
Group: group from bullet 4 above
Role: PVEAuditor
Propagate: Checked
Expand Permissions, click on Users
Click the Add button
User name: something informative like api
Realm: Linux PAM standard authentication
Group: group from bullet 4 above
Expand Permissions, click on API Tokens
Click the Add button
User: user from bullet 8 above
Token ID: something informative like the application or purpose like homepage
Privilege Separation: Checked
Go back to the \"Permissions\" menu
Click Add -> API Token Permission
Path: /
API Token: select the Token ID created in Step 10
Role: PVE Auditor
Propagate: Checked
Use username@pam!Token ID as the username (e.g api@pam!homepage) setting and Secret as the password setting.
This requires the httprpc plugin to be installed and enabled, and is part of the default ruTorrent plugins. If you have not explicitly removed or disable this plugin, it should be available.
Find your API key from inside Stash at Settings > Security > API Key. Note that the API key is only required if your Stash instance has login credentials.
You will need to generate an API access token from the keys page on the Tailscale dashboard.
To find your device ID, go to the machine overview page and select your machine. In the \"Machine Details\" section, copy your ID. It will end with CNTRL.
No extra configuration is required. If your traefik install requires authentication, include the username and password used to login to the web interface.
widget:\n type: transmission\n url: http://transmission.host.or.ip\n username: username\n password: password\n rpcUrl: /transmission/ # Optional. Matches the value of \"rpc-url\" in your Transmission's settings.json file\n
To create an API Key, follow the official TrueNAS documentation.
A detailed pool listing is disabled by default, but can be enabled with the enablePools option.
To use the enablePools option with TrueNAS Core, the nasType parameter is required.
widget:\n type: truenas\n url: http://truenas.host.or.ip\n username: user # not required if using api key\n password: pass # not required if using api key\n key: yourtruenasapikey # not required if using username / password\n enablePools: true # optional, defaults to false\n nasType: scale # defaults to scale, must be set to 'core' if using enablePools with TrueNAS Core\n
(Find the Unifi Controller information widget here)
You can display general connectivity status from your Unifi (Network) Controller. When authenticating you will want to use an account that has at least read privileges.
An optional 'site' parameter can be supplied, if it is not the widget will use the default site for the controller.
As Uptime Kuma does not yet have a full API the widget uses data from a single \"status page\". As such you will need a status page setup with a group of monitored sites, which is where you get the slug (the url without the /status/ portion). E.g. if your status page is URL http://uptimekuma.host/status/statuspageslug, insert slug: statuspageslug.
The UrBackup widget retrieves the total number of clients that currently have no errors, have errors, or haven't backed up recently. Clients are considered \"Errored\" or \"Out of Date\" if either the file or image backups for that client have errors/are out of date, unless the client does not support image backups.
The default number of days that can elapse before a client is marked Out of Date is 3, but this value can be customized by setting the maxDays value in the config.
Optionally, the widget can also report the total amount of disk space consumed by backups. This is disabled by default, because it requires a second API call.
Note: client status is only shown for backups that the specified user has access to. Disk Usage shown is the total for all backups, regardless of permissions.
Allowed fields: [\"ok\", \"errored\", \"noRecent\", \"totalUsed\"]. Note that totalUsed will not be shown unless explicitly included in fields.
"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stemmer","stopWordFilter","trimmer"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"
A modern, fully static, fast, secure fully proxied, highly customizable application dashboard with integrations for over 100 services and translations into multiple languages. Easily configured via YAML files or through docker label discovery.
Homepage uses YAML for configuration, YAML stands for \"YAML Ain't Markup Language.\". It's a human-readable data serialization format that's a superset of JSON. Great for config files, easy to read and write. Supports complex data types like lists and objects. Indentation matters. If you already use Docker Compose, you already use YAML.
Here are some tips when writing YAML:
Use Indentation Carefully: YAML relies on indentation, not brackets.
Avoid Tabs: Stick to spaces for indentation to avoid parsing errors. 2 spaces are common.
Quote Strings: Use single or double quotes for strings with special characters, this is especially important for API keys.
Key-Value Syntax: Use key: value format. Colon must be followed by a space.
Validate: Always validate your YAML with a linter before deploying.
You can find tons of online YAML validators, here's one: https://codebeautify.org/yaml-validator, heres another: https://jsonformatter.org/yaml-validator.
Bookmarks are configured in the bookmarks.yaml file. They function much the same as Services, in how groups and lists work. They're just much simpler, smaller, and contain no extra features other than being a link out.
The design of homepage expects abbr to be 2 letters, but is not otherwise forced.
You can also use an icon for bookmarks similar to the options for service icons. If both icon and abbreviation are supplied, the icon takes precedence.
By default, the description will use the hostname of the link, but you can override it with a custom description.
---\n- Developer:\n - Github:\n - abbr: GH\n href: https://github.com/\n\n- Social:\n - Reddit:\n - icon: reddit.png\n href: https://reddit.com/\n description: The front page of the internet\n\n- Entertainment:\n - YouTube:\n - abbr: YT\n href: https://youtube.com/\n
As of version v0.6.30 homepage supports adding your own custom css & javascript. Please do so at your own risk.
To add custom css simply edit the custom.css file under your config directory, similarly for javascript you would edit custom.js. You can then target elements in homepage with various classes / ids to customize things to your liking.
You can also set a specific id for a service or bookmark to target with your custom css or javascript, e.g.
Since Docker supports connecting with TLS and client certificate authentication, you can include TLS details when connecting to the HTTP API. Further details of setting up Docker to accept TLS connections, and generation of the keys and certs can be found in the Docker documentation. The file entries are relative to the config directory (location of docker.yaml file).
Due to security concerns with exposing the docker socket directly, you can use a docker-socket-proxy container to expose the docker socket on a more restricted and secure API.
Here is an example docker-compose file that will expose the docker socket, and then connect to it from the homepage container:
dockerproxy:\n image: ghcr.io/tecnativa/docker-socket-proxy:latest\n container_name: dockerproxy\n environment:\n - CONTAINERS=1 # Allow access to viewing containers\n - SERVICES=1 # Allow access to viewing services (necessary when using Docker Swarm)\n - TASKS=1 # Allow access to viewing tasks (necessary when using Docker Swarm)\n - POST=0 # Disallow any POST operations (effectively read-only)\n ports:\n - 127.0.0.1:2375:2375\n volumes:\n - /var/run/docker.sock:/var/run/docker.sock:ro # Mounted as read-only\n restart: unless-stopped\n\nhomepage:\n image: ghcr.io/gethomepage/homepage:latest\n container_name: homepage\n volumes:\n - /path/to/config:/app/config\n ports:\n - 3000:3000\n restart: unless-stopped\n
Then, inside of your docker.yaml settings file, you'd configure the docker instance like so:
Once you've configured your docker instances, you can then apply them to your services, to get stats and status reporting shown.
Inside of the service you'd like to connect to docker:
- Emby:\n icon: emby.png\n href: \"http://emby.home/\"\n description: Media server\n server: my-docker # The docker server that was configured\n container: emby # The name of the container you'd like to connect\n
"},{"location":"configs/docker/#automatic-service-discovery","title":"Automatic Service Discovery","text":"
Homepage features automatic service discovery for containers with the proper labels attached, all configuration options can be applied using dot notation, beginning with homepage.
Below is an example of the same service entry shown above, as docker labels.
When your Docker instance has been properly configured, this service will be automatically discovered and added to your Homepage. You do not need to specify the server or container values, as they will be automatically inferred.
Docker swarm is supported and Docker services are specified with the same server and container notation. To enable swarm support you will need to include a swarm setting in your docker.yaml, e.g.
For the automatic service discovery to discover all services it is important that homepage should be deployed on a manager node. Set deploy requirements to the master node in your stack yaml config, e.g.
In order to detect every service within the Docker swarm it is necessary that service labels should be used and not container labels. Specify the homepage labels as:
Once the Kubernetes connection is configured, individual services can be configured to pull statistics. Only CPU and Memory are currently supported.
Inside of the service you'd like to connect to a pod:
- Emby:\n icon: emby.png\n href: \"http://emby.home/\"\n description: Media server\n namespace: media # The kubernetes namespace the app resides in\n app: emby # The name of the deployed app\n
The app field is used to create a label selector, in this example case it would match pods with the label: app.kubernetes.io/name=emby.
Sometimes this is insufficient for complex or atypical application deployments. In these cases, the pod-selector field can be used. Any field selector can be used with it, so it allows for some very powerful selection capabilities.
For instance, it can be utilized to roll multiple underlying deployments under one application to see a high-level aggregate:
A blank string as a pod-selector does not deactivate it, but will actually select all pods in the namespace. This is a useful way to capture the resource usage of a complex application siloed to a single namespace, like Longhorn.
"},{"location":"configs/kubernetes/#automatic-service-discovery","title":"Automatic Service Discovery","text":"
Homepage features automatic service discovery by Ingress annotations. All configuration options can be applied using typical annotation syntax, beginning with gethomepage.dev/.
When the Kubernetes cluster connection has been properly configured, this service will be automatically discovered and added to your Homepage. You do not need to specify the namespace or app values, as they will be automatically inferred.
If you are using multiple instances of homepage, an instance annotation can be specified to limit services to a specific instance. If no instance is provided, the service will be visible on all instances.
Homepage can also read ingresses defined using the Traefik IngressRoute custom resource definition. Due to the complex nature of Traefik routing rules, it is required for the gethomepage.dev/href annotation to be set:
Similarly to Docker service discovery, there currently is no rigid ordering to discovered services and discovered services will be displayed above those specified in the services.yaml.
Each widget can optionally provide a list of which fields should be visible via the fields widget property. If no fields are specified, then all fields will be displayed. The fields property must be a valid YAML array of strings. As an example, here is the entry for Sonarr showing only a couple of fields.
In all cases a widget will work and display all fields without specifying the fields property.
- Group A:\n - Service A:\n href: http://localhost/\n\n - Service B:\n href: http://localhost/\n\n - Service C:\n href: http://localhost/\n\n- Group B:\n - Service D:\n href: http://localhost/\n
- Group A:\n - Service A:\n href: http://localhost/\n description: This is my service\n\n- Group B:\n - Service B:\n href: http://localhost/\n description: This is another service\n
Services may have an icon attached to them, you can use icons from Dashboard Icons automatically, by passing the name of the icon, with, or without .png or with .svg to use the svg version.
You can also specify prefixed icons from Material Design Icons with mdi-XX or Simple Icons with si-XX.
You can specify a custom color by adding a hex color code as suffix e.g. mdi-XX-#f0d453 or si-XX-#a712a2.
To use a remote icon, use the absolute URL (e.g. https://...).
To use a local icon, first create a Docker mount to /app/public/icons and then reference your icon as /icons/myicon.png. You will need to restart the container when adding new icons.
Warning
Material Design Icons for brands were deprecated and may be removed in the future. Using Simple Icons for brand icons will prevent any issues if / when the Material Design Icons are removed.
- Group A:\n - Sonarr:\n icon: sonarr.png\n href: http://sonarr.host/\n description: Series management\n\n- Group B:\n - Radarr:\n icon: radarr.png\n href: http://radarr.host/\n description: Movie management\n\n- Group C:\n - Service:\n icon: mdi-flask-outline\n href: http://service.host/\n description: My cool service\n
Services may have an optional ping property that allows you to monitor the availability of an external host. As of v0.8.0, the ping feature attempts to use a true (ICMP) ping command on the underlying host. Currently, only IPv4 is supported.
Services may have an optional siteMonitor property (formerly ping) that allows you to monitor the availability of a URL you chose and have the response time displayed. You do not need to set your monitor URL equal to your href or ping URL.
Note
The site monitor feature works by making an http HEAD request to the URL, and falls back to GET in case that fails. It will not, for example, login if the URL requires auth or is behind e.g. Authelia. In the case of a reverse proxy and/or auth this usually requires the use of an 'internal' URL to make the site monitor feature correctly display status.
Services may be connected to a Docker container, either running on the local machine, or a remote machine.
- Group A:\n - Service A:\n href: http://localhost/\n description: This is my service\n server: my-server\n container: my-container\n\n- Group B:\n - Service B:\n href: http://localhost/\n description: This is another service\n server: other-server\n container: other-container\n
Clicking on the status label of a service with Docker integration enabled will expand the container stats, where you can see CPU, Memory, and Network activity.
Note
This can also be controlled with showStats. See show docker stats for more information
The settings.yaml file allows you to define application level options. For changes made to this file to take effect, you will need to regenerate the static HTML, this can be done by clicking the refresh icon in the bottom right of the page.
You can specify filters to apply over your background image for blur, saturation and brightness as well as opacity to blend with the background color. The first three filter settings use tailwind CSS classes, see notes below regarding the options for each. You do not need to specify all options.
background:\n image: /images/background.png\n blur: sm # sm, \"\", md, xl... see https://tailwindcss.com/docs/backdrop-blur\n saturate: 50 # 0, 50, 100... see https://tailwindcss.com/docs/backdrop-saturate\n brightness: 50 # 0, 50, 75... see https://tailwindcss.com/docs/backdrop-brightness\n opacity: 50 # 0-100\n
You can apply a blur filter to the service & bookmark cards. Note this option is incompatible with the background blur, saturate and brightness filters.
cardBlur: sm # sm, \"\", md, etc... see https://tailwindcss.com/docs/backdrop-blur\n
If you'd like to use a custom favicon instead of the included one, you may provide a full URL to an image of your choice.
favicon: https://www.google.com/favicon.ico\n
Or you may pass the path to a local image relative to the /app/public directory. See Background Image for more detailed information on how to provide your own files.
Service groups and bookmark groups can be mixed in order, but should use different group names. If you do not specify any bookmark groups they will all show at the bottom of the page.
Using the same name for a service and bookmark group can cause unexpected behavior like a bookmark group being hidden
Groups will sort based on the order in the layout block. You can also mix in groups defined by docker labels, e.g.
The default style for icons (e.g. icon: mdi-XXXX) is a gradient, or you can specify that prefixed icons match your theme with a 'flat' style using the setting below. More information about prefixed icons can be found in options for service icons.
iconStyle: theme # optional, defaults to gradient\n
Version 0.6.30 introduced a tabbed view to layouts which can be optionally specified in the layout. Tabs is only active if you set the tab field on at least one layout group.
Tabs are sorted based on the order in the layout block. If a group has no tab specified (and tabs are set on other groups), services and bookmarks will be shown on all tabs.
Every tab can be accessed directly by visiting Homepage URL with #Group (name lowercase and URI-encoded) at the end of the URL.
For example, the following would create four tabs:
layout:\n ...\n Bookmark Group on First Tab:\n tab: First\n\n First Service Group:\n tab: First\n style: row\n columns: 4\n\n Second Service Group:\n tab: Second\n columns: 4\n\n Third Service Group:\n tab: Third\n style: row\n\n Bookmark Group on Fourth Tab:\n tab: Fourth\n\n Service Group on every Tab:\n style: row\n columns: 4\n
The providers section allows you to define shared API provider options and secrets. Currently this allows you to define your weather API keys in secret and is also the location of the Longhorn URL and credentials.
You can use the 'Quick Launch' feature to search services, perform a web search or open a URL. To use Quick Launch, just start typing while on your homepage (as long as the search widget doesn't have focus).
There are a few optional settings for the Quick Launch feature:
searchDescriptions: which lets you control whether item descriptions are included in searches. This is off by default. When enabled, results that match the item name will be placed above those that only match the description.
hideInternetSearch: disable automatically including the currently-selected web search (e.g. from the widget) as a Quick Launch option. This is false by default, enabling the feature.
showSearchSuggestions: shows search suggestions for the internet search. This value will be inherited from the search widget if it is not specified. If it is not specified there either, it will default to false.
hideVisitURL: disable detecting and offering an option to open URLs. This is false by default, enabling the feature.
By default the homepage logfile is written to the a logs subdirectory of the config folder. In order to customize this path, you can set the logpath setting. A logs folder will be created in that location where the logfile will be written.
logpath: /logfile/path\n
By default, logs are sent both to stdout and to a file at the path specified. This can be changed by setting the LOG_TARGETS environment variable to one of both (default), stdout or file.
You have a few options for deploying homepage, depending on your needs. We offer docker images for a majority of platforms. You can also install and run homepage from source if Docker is not your thing. It can even be installed on Kubernetes with Helm.
version: \"3.3\"\nservices:\n homepage:\n image: ghcr.io/gethomepage/homepage:latest\n container_name: homepage\n ports:\n - 3000:3000\n volumes:\n - /path/to/config:/app/config # Make sure your local config directory exists\n - /var/run/docker.sock:/var/run/docker.sock # (optional) For docker integrations\n
"},{"location":"installation/docker/#running-as-non-root","title":"Running as non-root","text":"
By default, the Homepage container runs as root. Homepage also supports running your container as non-root via the standard PUID and PGID environment variables. When using these variables, make sure that any volumes mounted in to the container have the correct ownership and permissions set.
Using the docker socket directly is not the recommended method of integration and requires either running homepage as root or that the user be part of the docker group
In the docker compose example below, the environment variables $PUID and $PGID are set in a .env file.
version: \"3.3\"\nservices:\n homepage:\n image: ghcr.io/gethomepage/homepage:latest\n container_name: homepage\n ports:\n - 3000:3000\n volumes:\n - /path/to/config:/app/config # Make sure your local config directory exists\n - /var/run/docker.sock:/var/run/docker.sock # (optional) For docker integrations, see alternative methods\n environment:\n PUID: $PUID\n PGID: $PGID\n
You can also include environment variables in your config files to protect sensitive information. Note:
Environment variables must start with HOMEPAGE_VAR_ or HOMEPAGE_FILE_
The value of env var HOMEPAGE_VAR_XXX will replace {{HOMEPAGE_VAR_XXX}} in any config
The value of env var HOMEPAGE_FILE_XXX must be a file path, the contents of which will be used to replace {{HOMEPAGE_FILE_XXX}} in any config
"},{"location":"installation/k8s/","title":"Kubernetes Installation","text":""},{"location":"installation/k8s/#install-with-helm","title":"Install with Helm","text":"
There is an unofficial helm chart that creates all the necessary manifests, including the service account and RBAC entities necessary for service discovery.
The helm chart allows for all the configurations to be inlined directly in your values.yaml:
config:\n bookmarks:\n - Developer:\n - Github:\n - abbr: GH\n href: https://github.com/\n services:\n - My First Group:\n - My First Service:\n href: http://localhost/\n description: Homepage is awesome\n\n - My Second Group:\n - My Second Service:\n href: http://localhost/\n description: Homepage is the best\n\n - My Third Group:\n - My Third Service:\n href: http://localhost/\n description: Homepage is \ud83d\ude0e\n widgets:\n # show the kubernetes widget, with the cluster summary and individual nodes\n - kubernetes:\n cluster:\n show: true\n cpu: true\n memory: true\n showLabel: true\n label: \"cluster\"\n nodes:\n show: true\n cpu: true\n memory: true\n showLabel: true\n - search:\n provider: duckduckgo\n target: _blank\n kubernetes:\n mode: cluster\n settings:\n\n# The service account is necessary to allow discovery of other services\nserviceAccount:\n create: true\n name: homepage\n\n# This enables the service account to access the necessary resources\nenableRbac: true\n\ningress:\n main:\n enabled: true\n annotations:\n # Example annotations to add Homepage to your Homepage!\n gethomepage.dev/enabled: \"true\"\n gethomepage.dev/name: \"Homepage\"\n gethomepage.dev/description: \"Dynamically Detected Homepage\"\n gethomepage.dev/group: \"Dynamic\"\n gethomepage.dev/icon: \"homepage.png\"\n hosts:\n - host: homepage.example.com\n paths:\n - path: /\n pathType: Prefix\n
"},{"location":"installation/k8s/#install-with-kubernetes-manifests","title":"Install with Kubernetes Manifests","text":"
If you don't want to use the unofficial Helm chart, you can also create your own Kubernetes manifest(s) and apply them with kubectl apply -f filename.yaml.
Here's a working example of the resources you need:
If you plan to deploy homepage with a replica count greater than 1, you may want to consider enabling sticky sessions on the homepage route. This will prevent unnecessary re-renders on page loads and window / tab focusing. The procedure for enabling sticky sessions depends on your Ingress controller. Below is an example using Traefik as the Ingress controller.
When you upload a new image into the /images folder, you will need to restart the container for it to show up in the WebUI. Please see the service icons for more information.
"},{"location":"more/","title":"More","text":"
Here you'll find resources and guides for Homepage, troubleshooting tips, and more.
Once dependencies have been installed you can lint your code with
pnpm lint\n
"},{"location":"more/development/#code-formatting-with-pre-commit-hooks","title":"Code formatting with pre-commit hooks","text":"
To ensure a consistent style and formatting across the project source, the project utilizes Git pre-commit hooks to perform some formatting and linting before a commit is allowed.
Once installed, hooks will run when you commit. If the formatting isn't quite right, the commit will be rejected and you'll need to look at the output and fix the issue. Most hooks will automatically format failing files, so all you need to do is git add those files again and retry your commit.
In general, homepage is meant to be a dashboard for 'self-hosted' services and we believe it is a small way we can help showcase this kind of software. While exceptions are made, mostly when there is no viable self-hosted / open-source alternative, we ask that any widgets, etc. are developed primarily for a self-hosted tool.
New features should be linked to an existing feature request with at least 10 'up-votes'. The purpose of this requirement is to avoid the addition (and maintenance) of features that might only benefit a small number of users.
If you have ideas for a larger feature, please open a discussion first.
Please note that though it is a requirement, a discussion with 10 'up-votes' in no way guarantees that a PR will be merged.
To ensure cohesiveness of various widgets, the following should be used as a guide for developing new widgets:
Please only submit widgets that have been requested and have at least 10 'up-votes'. The purpose of this requirement is to avoid the addition (and maintenance) of service widgets that might only benefit a small number of users.
Widgets should be only one row of blocks
Widgets should be no more than 4 blocks wide and generally conform to the styling / design choices of other widgets
Minimize the number of API calls
Avoid the use of custom proxy unless absolutely necessary
Widgets should be 'read-only', as in they should not make write changes using the relevant tool's API. Homepage widgets are designed to surface information, not to be a (usually worse) replacement for the tool itself.
As of v0.7.2 homepage migrated from benphelps/homepage to an \"organization\" repository located at gethomepage/homepage. The reason for this was to setup the project for longevity and allow for community maintenance.
Migrating your installation should be as simple as changing image: ghcr.io/benphelps/homepage:latest to image: ghcr.io/gethomepage/homepage:latest.
Homepage is developed in English, component contributions must be in English. All translations are community provided, so a huge thanks go out to all those who have helped out so far!
If you'd like to lend a hand in translating Homepage into more languages, or to improve existing translations, the process is very simple:
Create a free account at Crowdin
Visit the Homepage project
Select the language you'd like to translate
Start translating!
"},{"location":"more/translations/#adding-a-new-language","title":"Adding a new language","text":"
If you'd like to add a new language, please create a new Discussion on Crowdin, and we'll add it to the project.
"},{"location":"more/troubleshooting/","title":"Troubleshooting","text":""},{"location":"more/troubleshooting/#introducing-the-homepage-ai-bot","title":"Introducing the Homepage AI Bot","text":"
Thanks to the generous folks at Glime, Homepage is now equipped with a pretty clever AI-powered bot. The bot has full knowledge of our docs, GitHub issues and discussions and is great at answering specific questions about setting up your Homepage. To use the bot, just hit the 'Ask AI' button on any page in our docs, open a GitHub discussion or check out the #ai-support channel on Discord!
For API errors, clicking the \"API Error Information\" button in the widget will usually show some helpful information as to whether the issue is reaching the service host, an authentication issue, etc.
Check config/logs/homepage.log, on docker simply e.g. docker logs homepage. This may provide some insight into the reason for an error.
Check the browser error console, this can also sometimes provide useful information.
Consider setting the ENV variable LOG_LEVEL to debug.
All service widgets work essentially the same, that is, homepage makes a proxied call to an API made available by that service. The majority of the time widgets don't work it is a configuration issue. Of course, sometimes things do break. Some basic steps to try:
Ensure that you follow the rule mentioned on https://gethomepage.dev/latest/configs/service-widgets/. Unless otherwise noted, URLs should not end with a / or other API path. Each widget will handle the path on its own.. This is very important as including a trailing slash can result in an error.
Verify the homepage installation can connect to the IP address or host you are using for the widget url. This is most simply achieved by pinging the server from the homepage machine, in Docker this means from inside the container itself, e.g.:
docker exec homepage ping SERVICEIPORDOMAIN\n
If your homepage install (container) cannot reach the service then you need to figure out why, for example in Docker this can mean putting the two containers on the same network, checking firewall issues, etc.
If you have verified that homepage can in fact reach the service then you can also check the API output using e.g. curl, which is often helpful if you do need to file a bug report. Again, depending on your networking setup this may need to be run from inside the container as IP / hostname resolution can differ inside vs outside.
Note
curl is not installed in the base image by default but can be added inside the container with apk add curl.
The exact API endpoints and authentication vary of course, but in many cases instructions can be found by searching the web or if you feel comfortable looking at the homepage source code (e.g. src/widgets/{widget}/widget.js).
It is out of the scope of this to go into full detail about how to , but an example for PiHole would be:
If, after correctly adding and mapping your custom icons via the Icons instructions, you are still unable to see your icons please try recreating your container.
Service widgets are used to display the status of a service, often a web service or API. Services (and their widgets) are defined in your services.yaml file. Here's an example:
- Plex:\n icon: plex.png\n href: https://plex.my.host\n description: Watch movies and TV shows.\n server: localhost\n container: plex\n widget:\n type: tautulli\n url: http://172.16.1.1:8181\n key: aabbccddeeffgghhiijjkkllmmnnoo\n
Info widgets are used to display information in the header, often about your system or environment. Info widgets are defined your widgets.yaml file. Here's an example:
This allows you to display the date and/or time, can be heavily configured using Intl.DateTimeFormat.
Formatting is locale aware and will present your date in the regional format you expect, for example, 9/16/22, 3:03 PM for locale en and 16.09.22, 15:03 for de. You can also specify a locale just for the datetime widget with the locale option (see below).
The Glances widget allows you to monitor the resources (CPU, memory, storage, temp & uptime) of host or another machine, and is designed to match the resources info widget. You can have multiple instances by adding another configuration block. The cputemp, uptime & disk states require separate API calls and thus are not enabled by default. Glances needs to be running in \"web server\" mode to enable the API, see the glances docs.
- glances:\n url: http://host.or.ip:port\n username: user # optional if auth enabled in Glances\n password: pass # optional if auth enabled in Glances\n version: 4 # required only if running glances v4 or higher, defaults to 3\n cpu: true # optional, enabled by default, disable by setting to false\n mem: true # optional, enabled by default, disable by setting to false\n cputemp: true # disabled by default\n uptime: true # disabled by default\n disk: / # disabled by default, use mount point of disk(s) in glances. Can also be a list (see below)\n diskUnits: bytes # optional, bytes (default) or bbytes. Only applies to disk\n expanded: true # show the expanded view\n label: MyMachine # optional\n
This is very similar to the Resources widget, but provides resource information about a Kubernetes cluster.
It provides CPU and Memory usage, by node and/or at the cluster level.
- kubernetes:\n cluster:\n # Shows cluster-wide statistics\n show: true\n # Shows the aggregate CPU stats\n cpu: true\n # Shows the aggregate memory stats\n memory: true\n # Shows a custom label\n showLabel: true\n label: \"cluster\"\n nodes:\n # Shows node-specific statistics\n show: true\n # Shows the CPU for each node\n cpu: true\n # Shows the memory for each node\n memory: true\n # Shows the label, which is always the node name\n showLabel: true\n
The Longhorn widget pulls storage utilization metrics from the Longhorn storage driver on Kubernetes. It is designed to appear similar to the Resource widget's disk representation.
The exact metrics should be very similar to what is seen on the Longhorn dashboard itself.
It can show the aggregate metrics and/or the individual node metrics.
- longhorn:\n # Show the expanded view\n expanded: true\n # Shows a node representing the aggregate values\n total: true\n # Shows the node names as labels\n labels: true\n # Show the nodes\n nodes: true\n # An explicit list of nodes to show. All are shown by default if \"nodes\" is true\n include:\n - node1\n - node2\n
The Longhorn URL and credentials are stored in the providers section of the settings.yaml. e.g.:
The free tier \"One Call API\" is all that's required, you will need to subscribe and grab your API key.
- openweathermap:\n label: Kyiv #optional\n latitude: 50.449684\n longitude: 30.525026\n units: metric # or imperial\n provider: openweathermap\n apiKey: youropenweathermapkey # required only if not using provider, this reveals api key in requests\n cache: 5 # Time in minutes to cache API responses, to stay within limits\n format: # optional, Intl.NumberFormat options\n maximumFractionDigits: 1\n
You can optionally not pass a latitude and longitude and the widget will use your current location (requires a secure context, eg. HTTPS).
You can include all or some of the available resources. If you do not want to see that resource, simply pass false.
The disk path is the path reported by df (Mounted On), or the mount point of the disk.
The cpu and memory resource information are the container's usage while glances displays statistics for the host machine on which it is installed.
Note: unfortunately, the package used for getting CPU temp (systeminformation) is not compatible with some setups and will not report any value(s) for CPU temp.
Any disk you wish to access must be mounted to your container as a volume.
- resources:\n cpu: true\n memory: true\n disk: /disk/mount/path\n cputemp: true\n tempmin: 0 # optional, minimum cpu temp\n tempmax: 100 # optional, maximum cpu temp\n uptime: true\n units: imperial # only used by cpu temp\n refresh: 3000 # optional, in ms\n diskUnits: bytes # optional, bytes (default) or bbytes. Only applies to disk\n
You can also pass a label option, which allows you to group resources under named sections,
You can additionally supply an optional expanded property set to true in order to show additional details about the resources. By default the expanded property is set to false when not supplied.
You can add a search bar to your top widget area that can search using Google, Duckduckgo, Bing, Baidu, Brave or any other custom provider that supports the basic ?q= search query param.
- search:\n provider: google # google, duckduckgo, bing, baidu, brave or custom\n focus: true # Optional, will set focus to the search bar on page load\n showSearchSuggestions: true # Optional, will show search suggestions. Defaults to false\n target: _blank # One of _self, _blank, _parent or _top\n
The first entry of the array contains the search query, the second one is an array of the suggestions. In the example above, the search query was home.
You can display general connectivity status from your Unifi (Network) Controller. When authenticating you will want to use a local account that has at least read privileges.
An optional 'site' parameter can be supplied, if it is not the widget will use the default site for the controller.
Note: If you enter e.g. incorrect credentials and receive an \"API Error\", you may need to recreate the container to clear the cache.
- unifi_console:\n url: https://unifi.host.or.ip:port\n username: user\n password: pass\n site: Site Name # optional\n
Note: this widget is considered 'deprecated' since there is no longer a free Weather API tier for new members. See the openmeteo or openweathermap widgets for alternatives.
The free tier is all that's required, you will need to register and grab your API key.
- weatherapi:\n label: Kyiv # optional\n latitude: 50.449684\n longitude: 30.525026\n units: metric # or imperial\n apiKey: yourweatherapikey\n cache: 5 # Time in minutes to cache API responses, to stay within limits\n format: # optional, Intl.NumberFormat options\n maximumFractionDigits: 1\n
You can optionally not pass a latitude and longitude and the widget will use your current location (requires a secure context, eg. HTTPS).
This widget reads the number of active users in the system, as well as logins for the last 24 hours.
You will need to generate an API token for an existing user under Admin Portal > Directory > Tokens & App passwords. Make sure to set Intent to \"API Token\".
The account you made the API token for also needs the following Assigned global permissions in Authentik:
Pipelines: checks if the relevant pipeline is running or not, and if not, reports the last status. Allowed fields: [\"result\", \"status\"].
Pull Requests: returns the amount of open PRs, the amount of the PRs you have open, and how many PRs that you open are marked as 'Approved' by at least 1 person and not yet completed. Allowed fields: [\"totalPrs\", \"myPrs\", \"approved\"].
You will need to generate a personal access token for an existing user, see the azure documentation
widget:\n type: azuredevops\n organization: myOrganization\n project: myProject\n definitionId: pipelineDefinitionId # required for pipelines\n branchName: branchName # optional for pipelines, leave empty for all\n userEmail: email # required for pull requests\n repositoryId: prRepositoryId # required for pull requests\n key: personalaccesstoken\n
This widget shows monthly calendar, with optional integrations to show events from supported widgets.
widget:\n type: calendar\n firstDayInWeek: sunday # optional - defaults to monday\n view: monthly # optional - possible values monthly, agenda\n maxEvents: 10 # optional - defaults to 10\n showTime: true # optional - show time for event happening today - defaults to false\n timezone: America/Los_Angeles # optional and only when timezone is not detected properly (slightly slower performance) - force timezone for ical events (if it's the same - no change, if missing or different in ical - will be converted to this timezone)\n integrations: # optional\n - type: sonarr # active widget type that is currently enabled on homepage - possible values: radarr, sonarr, lidarr, readarr, ical\n service_group: Media # group name where widget exists\n service_name: Sonarr # service name for that widget\n color: teal # optional - defaults to pre-defined color for the service (teal for sonarr)\n params: # optional - additional params for the service\n unmonitored: true # optional - defaults to false, used with *arr stack\n - type: ical # Show calendar events from another service\n url: https://domain.url/with/link/to.ics # URL with calendar events\n name: My Events # required - name for these calendar events\n color: zinc # optional - defaults to pre-defined color for the service (zinc for ical)\n params: # optional - additional params for the service\n showName: true # optional - show name before event title in event line - defaults to false\n
This view shows only list of events from configured integrations
widget:\n type: calendar\n view: agenda\n maxEvents: 10 # optional - defaults to 10\n showTime: true # optional - show time for event happening today - defaults to false\n previousDays: 3 # optional - shows events since three days ago - defaults to 0\n integrations: # same as in Monthly view example\n
This custom integration allows you to show events from any calendar that supports iCal format, for example, Google Calendar (go to Settings, select specific calendar, go to Integrate calendar, copy URL from Public Address in iCal format).
As of v0.6.10 this widget no longer accepts a Cloudflare global API key (or account email) due to security concerns. Instead, you should setup an API token which only requires the permissions Account.Cloudflare Tunnel:Read.
Allowed fields: [\"status\", \"origin_ip\"].
widget:\n type: cloudflared\n accountid: accountid # from zero trust dashboard url e.g. https://one.dash.cloudflare.com/<accountid>/home/quick-start\n tunnelid: tunnelid # found in tunnels dashboard under the tunnel name\n key: cloudflareapitoken # api token with `Account.Cloudflare Tunnel:Read` https://dash.cloudflare.com/profile/api-tokens\n
See the crowdsec docs for information about registering a machine, in most instances you can use the default credentials (/etc/crowdsec/local_api_credentials.yaml).
This widget can show information from custom self-hosted or third party API.
Fields need to be defined in the mappings section YAML object to correlate with the value in the APIs JSON object. Final field definition needs to be the key with the desired value information.
widget:\n type: customapi\n url: http://custom.api.host.or.ip:port/path/to/exact/api/endpoint\n refreshInterval: 10000 # optional - in milliseconds, defaults to 10s\n username: username # auth - optional\n password: password # auth - optional\n method: GET # optional, e.g. POST\n headers: # optional, must be object, see below\n requestBody: # optional, can be string or object, see below\n display: # optional, default to block, see below\n mappings:\n - field: key # needs to be YAML string or object\n label: Field 1\n format: text # optional - defaults to text\n - field: # needs to be YAML string or object\n path:\n to: key2\n format: number # optional - defaults to text\n label: Field 2\n - field: # needs to be YAML string or object\n path:\n to:\n another: key3\n label: Field 3\n format: percent # optional - defaults to text\n - field: key # needs to be YAML string or object\n label: Field 4\n format: date # optional - defaults to text\n locale: nl # optional\n dateStyle: long # optional - defaults to \"long\". Allowed values: `[\"full\", \"long\", \"medium\", \"short\"]`.\n timeStyle: medium # optional - Allowed values: `[\"full\", \"long\", \"medium\", \"short\"]`.\n - field: key # needs to be YAML string or object\n label: Field 5\n format: relativeDate # optional - defaults to text\n locale: nl # optional\n style: short # optional - defaults to \"long\". Allowed values: `[\"long\", \"short\", \"narrow\"]`.\n numeric: auto # optional - defaults to \"always\". Allowed values `[\"always\", \"auto\"]`.\n - field: key\n label: Field 6\n format: text\n additionalField: # optional\n field:\n hourly:\n time: other key\n color: theme # optional - defaults to \"\". Allowed values: `[\"theme\", \"adaptive\", \"black\", \"white\"]`.\n format: date # optional\n
Supported formats for the values are text, number, float, percent, bytes, bitrate, date and relativeDate.
The dateStyle and timeStyle options of the date format are passed directly to Intl.DateTimeFormat and the style and numeric options of relativeDate are passed to Intl.RelativeTimeFormat.
You can manipulate data with the following tools remap, scale, prefix and suffix, for example:
- field: key4\n label: Field 4\n format: text\n remap:\n - value: 0\n to: None\n - value: 1\n to: Connected\n - any: true # will map all other values\n to: Unknown\n- field: key5\n label: Power\n format: float\n scale: 0.001 # can be number or string e.g. 1/16\n suffix: \"kW\"\n- field: key6\n label: Price\n format: float\n prefix: \"$\"\n
You can change the default block view to a list view by setting the display option to list.
The list view can optionally display an additional field next to the primary field.
additionalField: Similar to field, but only used in list view. Displays additional information for the mapping object on the right.
field: Defined the same way as other custom api widget fields.
color: Allowed options: \"theme\", \"adaptive\", \"black\", \"white\". The option adaptive will apply a color using the value of the additionalField, green for positive numbers, red for negative numbers.
- field: key\n label: Field\n format: text\n remap:\n - value: 0\n to: None\n - value: 1\n to: Connected\n - any: true # will map all other values\n to: Unknown\n additionalField:\n field:\n hourly:\n time: key\n color: theme\n format: date\n
"},{"location":"widgets/services/diskstation/","title":"Synology Disk Station","text":"
Learn more about Synology Disk Station.
Note: the widget is not compatible with 2FA.
An optional 'volume' parameter can be supplied to specify which volume's free space to display when more than one volume exists. The value of the parameter must be in form of volume_N, e.g. to display free space for volume2, volume_2 should be set as 'volume' value. If omitted, first returned volume's free space will be shown (not guaranteed to be volume1).
To access these system metrics you need to connect to the DiskStation (DSM) with an account that is a member of the default Administrators group. That is because these metrics are requested from the API's SYNO.Core.System part that is only available to admin users. In order to keep the security impact as small as possible we can set the account in DSM up to limit the user's permissions inside the Synology system. In DSM 7.x, for instance, follow these steps:
Create a new user, i.e. remote_stats.
Set up a strong password for the new user
Under the User Groups tab of the user config dialogue check the box for Administrators.
On the Permissions tab check the top box for No Access, effectively prohibiting the user from accessing anything in the shared folders.
Under Applications check the box next to Deny in the header to explicitly prohibit login to all applications.
Now only allow login to the DSM application, either by
unchecking Deny in the respective row, or (if inheriting permission doesn't work because of other group settings)
checking Allow for this app, or
checking By IP for this app to limit the source of login attempts to one or more IP addresses/subnets.
When the Preview column shows Allow in the DSM row, click Save.
Now configure the widget with the correct login information and test it.
If you encounter issues during testing:
Make sure to uncheck the option for automatic blocking due to invalid logins under Control Panel > Security > Protection.
If desired, this setting can be reactivated once the login is established working.
Login to your Synology DSM with the newly created account and accept terms and conditions.
You can create an API key from inside Emby at Settings > Advanced > Api Keys.
As of v0.6.11 the widget supports fields [\"movies\", \"series\", \"episodes\", \"songs\"]. These blocks are disabled by default but can be enabled with the enableBlocks option, and the \"Now Playing\" feature (enabled by default) can be disabled with the enableNowPlaying option.
widget:\n type: emby\n url: http://emby.host.or.ip\n key: apikeyapikeyapikeyapikeyapikey\n enableBlocks: true # optional, defaults to false\n enableNowPlaying: true # optional, defaults to true\n enableUser: true # optional, defaults to false\n showEpisodeNumber: true # optional, defaults to false\n expandOneStreamToTwoRows: false # optional, defaults to true\n
Show the number of ESPHome devices based on their state.
Allowed fields: [\"total\", \"online\", \"offline\", \"offline_alt\", \"unknown\"] (maximum of 4).
By default ESPHome will only mark devices as offline if their address cannot be pinged. If it has an invalid config or its name cannot be resolved (by DNS) its status will be marked as unknown. To group both offline and unknown devices together, users should use the offline_alt field instead. This sums all devices that are not online together.
Application access & UPnP must be activated on your device:
Home Network > Network > Network Settings > Access Settings in the Home Network\n[x] Allow access for applications\n[x] Transmit status information over UPnP\n
Credentials are not needed and, as such, you may want to consider using http instead of https as those requests are significantly faster.
Allowed fields (limited to a max of 4): [\"connectionStatus\", \"uptime\", \"maxDown\", \"maxUp\", \"down\", \"up\", \"received\", \"sent\", \"externalIPAddress\"].
The Glances widget allows you to monitor the resources (cpu, memory, diskio, sensors & processes) of host or another machine. You can have multiple instances by adding another service block.
widget:\n type: glances\n url: http://glances.host.or.ip:port\n username: user # optional if auth enabled in Glances\n password: pass # optional if auth enabled in Glances\n version: 4 # required only if running glances v4 or higher, defaults to 3\n metric: cpu\n diskUnits: bytes # optional, bytes (default) or bbytes. Only applies to disk\n refreshInterval: 5000 # optional - in milliseconds, defaults to 1000 or more, depending on the metric\n pointsLimit: 15 # optional, defaults to 15\n
Please note, this widget does not need an href, icon or description on its parent service. To achieve the same effect as the examples above, see as an example:
The metric field in the configuration determines the type of system monitoring data to be displayed. Here are the supported metrics:
info: System information. Shows the system's hostname, OS, kernel version, CPU type, CPU usage, RAM usage and SWAP usage.
cpu: CPU usage. Shows how much of the system's computational resources are currently being used.
memory: Memory usage. Shows how much of the system's RAM is currently being used.
process: Top 5 processes based on CPU usage. Gives an overview of which processes are consuming the most resources.
network:<interface_name>: Network data usage for the specified interface. Replace <interface_name> with the name of your network interface, e.g., network:enp0s25, as specified in glances.
sensor:<sensor_id>: Temperature of the specified sensor, typically used to monitor CPU temperature. Replace <sensor_id> with the name of your sensor, e.g., sensor:Package id 0 as specified in glances.
disk:<disk_id>: Disk I/O data for the specified disk. Replace <disk_id> with the id of your disk, e.g., disk:sdb, as specified in glances.
gpu:<gpu_id>: GPU usage for the specified GPU. Replace <gpu_id> with the id of your GPU, e.g., gpu:0, as specified in glances.
fs:<mnt_point>: Disk usage for the specified mount point. Replace <mnt_point> with the path of your disk, e.g., /mnt/storage, as specified in glances.
Specify a single check by including the uuid field or show the total 'up' and 'down' for all checks by leaving off the uuid field.
To use the Health Checks widget, you first need to generate an API key.
In your project, go to project Settings on the navigation bar.
Click on API key (read-only) and then click Create.
Copy the API key that is generated for you.
Allowed fields: [\"status\", \"last_ping\"] for single checks, [\"up\", \"down\"] for total stats.
widget:\n type: healthchecks\n url: http://healthchecks.host.or.ip:port\n key: <YOUR_API_KEY>\n uuid: <CHECK_UUID> # optional, if not included total statistics for all checks is shown\n
Up to a maximum of four custom states and/or templates can be queried via the custom property like in the example below. The custom property will have no effect as long as the fields property is defined.
state will query the state of the specified entity_id
state labels and values can be user defined and may reference entity attributes in curly brackets
if no state label is defined it will default to \"{attributes.friendly_name}\"
if no state value is defined it will default to \"{state} {attributes.unit_of_measurement}\"
template will query the specified template, see Home Assistant Templating
The Homebridge API is actually provided by the Config UI X plugin that has been included with Homebridge for a while, still it is required to be installed for this widget to work.
You can create an API key from inside Jellyfin at Settings > Advanced > Api Keys.
As of v0.6.11 the widget supports fields [\"movies\", \"series\", \"episodes\", \"songs\"]. These blocks are disabled by default but can be enabled with the enableBlocks option, and the \"Now Playing\" feature (enabled by default) can be disabled with the enableNowPlaying option.
widget:\n type: jellyfin\n url: http://jellyfin.host.or.ip\n key: apikeyapikeyapikeyapikeyapikey\n enableBlocks: true # optional, defaults to false\n enableNowPlaying: true # optional, defaults to true\n enableUser: true # optional, defaults to false\n showEpisodeNumber: true # optional, defaults to false\n expandOneStreamToTwoRows: false # optional, defaults to true\n
Use the base URL of the Mastodon instance you'd like to pull stats for. Does not require authentication as the stats are part of the public API endpoints.
If your moonraker instance has an active authorization and your homepage ip isn't whitelisted you need to add your api key (Authorization Documentation).
Use username & password, or the NC-Token key. Information about the token can be found under Settings > System. If both are provided, NC-Token will be used.
This widget uses the same authentication method as your browser when logging in (HTTP Basic Auth), and is often referred to as the ControlUsername and ControlPassword inside of Nzbget documentation.
The method field determines the type of data to be displayed and is required. Supported methods:
services.getStatus: Shows status of running services. Allowed fields: [\"running\", \"stopped\", \"total\"]
smart.getListBg: Shows S.M.A.R.T. status from disks. Allowed fields: [\"passed\", \"failed\"]
downloader.getDownloadList: Displays the number of tasks from the Downloader plugin currently being downloaded and total. Allowed fields: [\"downloading\", \"total\"]
The API key & secret can be generated via the webui by creating a new user at System/Access/Users. Ensure \"Generate a scrambled password to prevent local database logins for this user\" is checked and then edit the effective privileges selecting only:
Diagnostics: System Activity
Status: Traffic Graph
Finally, create a new API key which will download an apikey.txt file with your key and secret in it. Use the values as the username and password fields, respectively, in your homepage config.
Use username & password, or the token key. Information about the token can be found in the Paperless-ngx API documentation. If both are provided, the token will be used.
This widget requires an additional tool, PeaNUT, as noted. Other projects exist to achieve similar results using a customapi widget, for example NUTCase.
This widget requires the installation of the pfsense-api which is a 3rd party package for pfSense routers.
Once pfSense API is installed, you can set the API to be read-only in System > API > Settings.
There are two currently supported authentication modes: 'Local Database' and 'API Token'. For 'Local Database', use username and password with the credentials of an admin user. For 'API Token', utilize the headers parameter with client_token and client_id obtained from pfSense as shown below. Do not use both headers and username / password.
The interface to monitor is defined by updating the wan parameter. It should be referenced as it is shown under Interfaces > Assignments in pfSense.
Load is returned instead of cpu utilization. This is a limitation in the pfSense API due to the complexity of this calculation. This may become available in future versions.
As of v2022.12 PiHole requires the use of an API key if an admin password is set. Older versions do not require any authentication even if the admin uses a password.
Note: by default the \"blocked\" and \"blocked_percent\" fields are merged e.g. \"1,234 (15%)\" but explicitly including the \"blocked_percent\" field will change them to display separately.
widget:\n type: pihole\n url: http://pi.hole.or.ip\n version: 6 # required if running v6 or higher, defaults to 5\n key: yourpiholeapikey # optional\n
The core Plex API is somewhat limited but basic info regarding library sizes and the number of active streams is supported. For more detailed info regarding active streams see the Plex Tautulli widget.
You'll need to make sure you have the correct environment set for the integration to work properly. From the Environments section inside of Portainer, click the one you'd like to connect to and observe the ID at the end of the URL (should be), something like #!/endpoints/1, here 1 is the value to set as the env value. In order to generate an API key, please follow the steps outlined here https://docs.portainer.io/api/access.
This widget shows the running and total counts of both QEMU VMs and LX Containers in the Proxmox cluster. It also shows the CPU and memory usage of the first node in the cluster.
You will need to generate an API Token for new or an existing user. Here is an example of how to do this for a new user.
Navigate to the Proxmox portal, click on Datacenter
Expand Permissions, click on Groups
Click the Create button
Name the group something informative, like api-ro-users
Click on the Permissions \"folder\"
Click Add -> Group Permission
Path: /
Group: group from bullet 4 above
Role: PVEAuditor
Propagate: Checked
Expand Permissions, click on Users
Click the Add button
User name: something informative like api
Realm: Linux PAM standard authentication
Group: group from bullet 4 above
Expand Permissions, click on API Tokens
Click the Add button
User: user from bullet 8 above
Token ID: something informative like the application or purpose like homepage
Privilege Separation: Checked
Go back to the \"Permissions\" menu
Click Add -> API Token Permission
Path: /
API Token: select the Token ID created in Step 10
Role: PVE Auditor
Propagate: Checked
Use username@pam!Token ID as the username (e.g api@pam!homepage) setting and Secret as the password setting.
This requires the httprpc plugin to be installed and enabled, and is part of the default ruTorrent plugins. If you have not explicitly removed or disable this plugin, it should be available.
Find your API key from inside Stash at Settings > Security > API Key. Note that the API key is only required if your Stash instance has login credentials.
You will need to generate an API access token from the keys page on the Tailscale dashboard.
To find your device ID, go to the machine overview page and select your machine. In the \"Machine Details\" section, copy your ID. It will end with CNTRL.
No extra configuration is required. If your traefik install requires authentication, include the username and password used to login to the web interface.
widget:\n type: transmission\n url: http://transmission.host.or.ip\n username: username\n password: password\n rpcUrl: /transmission/ # Optional. Matches the value of \"rpc-url\" in your Transmission's settings.json file\n
To create an API Key, follow the official TrueNAS documentation.
A detailed pool listing is disabled by default, but can be enabled with the enablePools option.
To use the enablePools option with TrueNAS Core, the nasType parameter is required.
widget:\n type: truenas\n url: http://truenas.host.or.ip\n username: user # not required if using api key\n password: pass # not required if using api key\n key: yourtruenasapikey # not required if using username / password\n enablePools: true # optional, defaults to false\n nasType: scale # defaults to scale, must be set to 'core' if using enablePools with TrueNAS Core\n
(Find the Unifi Controller information widget here)
You can display general connectivity status from your Unifi (Network) Controller. When authenticating you will want to use an account that has at least read privileges.
An optional 'site' parameter can be supplied, if it is not the widget will use the default site for the controller.
As Uptime Kuma does not yet have a full API the widget uses data from a single \"status page\". As such you will need a status page setup with a group of monitored sites, which is where you get the slug (the url without the /status/ portion). E.g. if your status page is URL http://uptimekuma.host/status/statuspageslug, insert slug: statuspageslug.
The UrBackup widget retrieves the total number of clients that currently have no errors, have errors, or haven't backed up recently. Clients are considered \"Errored\" or \"Out of Date\" if either the file or image backups for that client have errors/are out of date, unless the client does not support image backups.
The default number of days that can elapse before a client is marked Out of Date is 3, but this value can be customized by setting the maxDays value in the config.
Optionally, the widget can also report the total amount of disk space consumed by backups. This is disabled by default, because it requires a second API call.
Note: client status is only shown for backups that the specified user has access to. Disk Usage shown is the total for all backups, regardless of permissions.
Allowed fields: [\"ok\", \"errored\", \"noRecent\", \"totalUsed\"]. Note that totalUsed will not be shown unless explicitly included in fields.
Note: by default [\"connected\", \"enabled\", \"total\"] are displayed.
To detect if a device is connected the time since the last handshake is queried. threshold is the time to wait in minutes since the last handshake to consider a device connected. Default is 2 minutes.
Note: by default ["connected", "enabled", "total"] are displayed.
+
To detect if a device is connected the time since the last handshake is queried. threshold is the time to wait in minutes since the last handshake to consider a device connected. Default is 2 minutes.