# Dynacat: dynamic self-hosted dashboard review

> Dynacat is a Go-based, self-hosted dashboard for combining external information, automating widget updates and exposing fetched widget data through JSON. Its visual editors are useful, but deployment and external-service dependencies shape its value.

**Panonim/dynacat** — Dynacat is a dashboard focused on dynamic reloading and easy integration with external applications. 

- Repository: https://github.com/Panonim/dynacat
- Website: https://dynacat.artur.zone/
- Stars: 1,529 · Forks: 49
- Language: Go
- License: AGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/panonim-dynacat

## What Dynacat consolidates on a self-hosted dashboard

Dynacat addresses the problem of assembling changing information from separate web services into one private dashboard. It is aimed at people who self-host software and want news feeds, service status, machine statistics and application-specific data visible without maintaining a separate frontend for each source. The README identifies RSS, Subreddit posts, Hacker News, weather, YouTube, Twitch, market prices, Docker containers and server statistics among the available widgets.

The project is not limited to RSS, despite its repository topics. It can also expose fetched widget data through a JSON API, fetch ready-made Dynawidgets from a community repository and connect to external applications through custom API widgets. This makes Dynacat a presentation and aggregation layer rather than merely an RSS reader.

Dynacat was forked from Glance. According to the README, the fork focuses on dynamic content updates and integration with external applications. That distinction matters because Dynacat adds automatic widget refresh, a visual page and widget editor, JSON access and an editor for `custom-api` widgets. It remains a self-hosted application built primarily in Go, with a small Alpine-based container and a documented binary distribution.

## How Dynacat fetches, renders and updates widget data

Dynacat uses YAML as the persistent configuration model. Pages contain columns, and each column contains widgets, so layout and integration settings remain explicit and reviewable in files. A widget can also contain nested groups, as the example does when grouping Hacker News with Lobsters and two Reddit widgets. This structure separates dashboard layout from the external sources each widget queries.

The data flow is source-oriented. Dynacat fetches data from a configured feed or service, renders it in the browser as a dashboard widget and refreshes dynamic content without requiring a manual page reload. The JSON API provides another path into data that widgets have already fetched, allowing scripts or other applications to consume the results. The visual widget editor works with `custom-api` widgets by pointing at an API and binding interface blocks to returned fields.

Configuration can be changed in two ways. The UI editor lets users add pages, move widgets between columns and alter options from the dashboard. Dynacat writes those changes into the same YAML files used by manual editing. Hand-written configuration therefore remains part of the application model rather than being replaced by a database-only editor.

The repository layout supports this application model through Go packages under `internal/` and `pkg/`, with `main.go` as the entry point. The `go.mod` file includes feed parsing through `github.com/mmcdole/gofeed`, OIDC through `github.com/coreos/go-oidc/v3`, YAML support through `gopkg.in/yaml.v3`, JSON field access through `github.com/tidwall/gjson`, file watching through `github.com/fsnotify/fsnotify`, SQLite through `modernc.org/sqlite` and system statistics through `github.com/shirou/gopsutil/v4`.

## Installing Dynacat with the Compose template

The README recommends Docker Compose and a ready-made template directory. This is the clearest first deployment because the template supplies the expected directory structure. The documented command downloads the latest template archive, extracts it and starts Dynacat in the background:

```bash
mkdir dynacat && cd dynacat && \
curl -sL https://github.com/Panonim/dynacat-compose-template/releases/latest/download/dynacat.tar.gz | tar -xzf - && \
docker compose up -d
```

After the command succeeds, the README's Compose file maps the container's port 8080 to the host's port 8080. It mounts `./config` at `/app/config` and `./assets` at `/app/assets`, both of which should remain available to the container. The image name is `panonim/dynacat`, and the container name is `dynacat`.

The corresponding service definition is documented as follows:

```yaml
services:
  dynacat:
    container_name: dynacat
    image: panonim/dynacat
    restart: unless-stopped
    volumes:
      - ./config:/app/config
      - ./assets:/app/assets
      - /etc/localtime:/etc/localtime:ro
      # - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - 8080:8080
    env_file: .env
```

The Docker socket line is optional and is only needed for the Docker containers widget. Even when mounted read-only, granting container access to the Docker socket expands the host control surface, so it should not be enabled merely by habit. OIDC is supported, but the README excerpt does not provide a complete identity-provider configuration example, so that setup must be verified in the linked configuration documentation.

## A first RSS dashboard written in YAML

After starting the container, the first useful configuration can be created in the UI or written into the mounted configuration directory. The README's preview begins with a page named `Home`, followed by small and full columns. This example is useful because it shows the configuration grammar without requiring an undocumented shortcut.

```yaml
- name: Home
  columns:
    - size: small
      widgets:
        - type: calendar
          first-day-of-week: monday
        - type: rss
          limit: 10
          collapse-after: 3
          cache: 12h
          feeds:
            - url: https://selfh.st/rss/
              title: selfh.st
              limit: 4
            - url: https://ciechanow.ski/atom.xml
```

This entry defines the first day of the week, requests ten RSS items, collapses the display after three entries and assigns a 12-hour cache. Individual feeds can override the general limit, as `selfh.st` does with `limit: 4`. The cache key is part of the documented widget configuration and can also affect how often Dynacat asks the source for data.

A custom integration follows a different route. Rather than manually constructing a full API template, the documented widget editor lets a user select fields returned by an API and bind those values to blocks in the interface. For a first use, an RSS widget is easier to validate because its feed URL, display limit and cache policy are visible in YAML. A custom API should be added only after confirming the external service returns the fields Dynacat can bind.

## External services, refresh timing and network failure modes

Dynacat's principal failure mode is dependency failure. A widget can be configured correctly while still returning stale or empty content if its feed, API, DNS resolver or network path fails. The README's common-issues section begins discussing request timeouts and identifies Pi-Hole or AdGuard as a common cause, although the available documentation text is truncated before it provides a complete diagnostic procedure. That makes those services a documented troubleshooting lead, not proof of the cause in a particular installation.

Automatic refresh does not remove this constraint. It changes when Dynacat attempts to update information, but it cannot guarantee that a remote endpoint responds. Cache settings provide another layer of delay, and the documented market, release and RSS widgets can use cache values such as `12h` or `1d`. Operators should therefore distinguish a Dynacat rendering problem from a source, cache or local network problem before changing widget settings.

The JSON API is also limited to widget data Dynacat has already fetched, according to the README. It is not documented as a general proxy for arbitrary requests. This boundary makes it useful for sharing existing dashboard data with local scripts, but it does not remove the need to understand each widget's upstream service and refresh behavior.

## Dynacat compared with upstream Glance and static dashboards

Glance is the clearest documented alternative because Dynacat is explicitly described as a fork of it. The practical distinction is Dynacat's focus on changing content and integration with external applications. Its documented additions include dynamic updates, JSON access to fetched widget data, the visual `custom-api` widget builder, Dynawidgets delivery by slug and a UI editor that writes layout changes back to YAML.

A static page is a different kind of tool. It can be simpler to deploy and can continue presenting its saved content without contacting upstream services. Dynacat instead trades some of that independence for live feeds, service widgets, caching and application integration. Dynacat is therefore better suited to users who value current information and dashboard configuration, while a static page fits content that changes infrequently or must remain available without upstream requests.

The AGPL-3.0 license is also relevant when comparing adoption options. Anyone modifying Dynacat or distributing a modified version should review the repository's `LICENSE` file and assess its obligations for the intended deployment and distribution model. This article does not interpret the license or provide legal advice.

## Release cadence and upgrade work in Dynacat

Dynacat is not archived, and its last push was on 2026-10-16. The release history supplied with the repository records version 3.0.1 on 2026-10-05, version 3.0.0 on 2026-09-12 and version 2.4.0 on 2026-06-29. These dates indicate recent project activity, but the release descriptions do not provide migration instructions or compatibility details for upgrading an existing installation.

The persistent state that deserves attention during upgrades is visible in the Compose setup: `/app/config`, `/app/assets` and the `.env` file. Backups of those paths are more directly relevant than rebuilding the container itself. The repository also has separate `Dockerfile` and `Dockerfile.goreleor` build definitions, but the README does not explain whether one is preferred for a particular deployment or document a formal upgrade command beyond starting the Compose service.

For source builds, `go.mod` declares Go 1.26.0, while the container uses the `golang:1.26-alpine` builder and an Alpine 3.21 runtime. A team maintaining its own build pipeline should treat those version declarations as the first compatibility checks rather than assuming an older local Go toolchain can reproduce the documented container build.

## Conclusion

Dynacat suits self-hosting users who want several changing data sources in one configurable dashboard and are comfortable managing Docker and YAML-backed configuration. It is less suitable for users who need a fully manual static display, guaranteed offline operation or integrations beyond the documented widgets. Before adopting it, verify the Docker image, port 8080, writable configuration volume and each external API or feed used by the first dashboard.

## FAQ

### How do I install Dynacat with Docker Compose?

The README recommends downloading `dynacat.tar.gz` from the `dynacat-compose-template` release, extracting it into a `dynacat` directory and running `docker compose up -d`. The documented Compose service exposes port 8080 and mounts `./config` and `./assets`.

### Can I edit a Dynacat dashboard without changing YAML manually?

Yes. The UI editor can add pages, move widgets between columns and change widget options, with Dynacat writing the result into YAML. A visual builder is also available for `custom-api` widgets.

### Does Dynacat update widgets automatically?

The README states that widgets refresh dynamically without a manual page reload. Update timing can still be affected by cache settings and the availability of the configured feed or API.

### What external data can Dynacat display?

Documented widgets include RSS feeds, Reddit, Hacker News, weather, YouTube, Twitch, markets, Docker container status and server statistics. Dynacat also supports custom API widgets, community Dynawidgets and additional widget types listed in its documentation.

### What should I check when a Dynacat request times out?

The README's common-issues section identifies Pi-Hole and AdGuard as common causes of request timeouts, but the available text does not provide a complete troubleshooting procedure. Check the local DNS or filtering path and the configured external source before treating the timeout as a dashboard rendering fault.

## Sources

- [License: AGPL-3.0](https://github.com/Panonim/dynacat/blob/main/LICENSE)
- [Panonim/dynacat on GitHub](https://github.com/Panonim/dynacat)
- [Project website](https://dynacat.artur.zone/)
- [README](https://github.com/Panonim/dynacat/blob/main/README.md)
- [Releases](https://github.com/Panonim/dynacat/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/panonim-dynacat