Forem: DacForge

Self-hosted analytics on Coolify with Umami

DacForge — Sat, 18 Apr 2026 09:18:59 +0000

When we launched dacforge.com two days ago we shipped it with no analytics. No Google tag, no Plausible, no anything. The privacy posture on the home page said "we run our own infrastructure"; putting a third-party tracker on the site would have been a visible contradiction on line one.

Two days in, that stance had already stopped being defensible. The site had traffic we could not explain, referrers we could not trace, and pages whose value we could not compare. "No analytics" is a purist line that works until you need to make a decision, and then you have nothing. The honest move was not to hold the line; it was to pick a tool that would let us keep most of the privacy posture intact and add just enough visibility to act on.

Today we deployed Umami on the same Hetzner box that serves this site, behind https://analytics.dacforge.com, and flipped the tracker on in Base.astro. Here is what shipped, why Umami over the other four options we evaluated, and the short version of the legal posture on /privacy.

The constraints

Before tool shopping, we wrote down what would make a choice a yes or a no.

Self-hosted. We cannot sell "run your own infrastructure" to clients while running a third-party tracker on our own site. Fathom and Simple Analytics (SaaS-only) fell out here.
Cookieless. A cookie banner on our own site would advertise the same contradiction. Rules out GA4 as configured for most sites.
Low maintenance. A 2-person studio does not want a tool that needs twice-yearly CPU-feature checks, SMTP config, three-database compose files, and UID-999 permission dances.
Free to run. We already pay for the Hetzner box. No monthly SaaS fee.
Cookieless implementation that survives legal review. First-party, no cross-site identifier, no cookies, clear disclosure, one-click opt-out.

Five tools cleared the first filter: Umami, Plausible Community Edition, GA4, GoAccess, and do-nothing. Umami won. The rest of this post is the build, then the short version of why the other four did not.

The build, in five minutes

Coolify one-click

Umami is an official Coolify one-click service in the Analytics category. The template is pinned to ghcr.io/umami-software/umami:3.0.3 with postgres:16-alpine, exposes port 3000 (which matches Coolify's UI default, so no port override), and uses Coolify's magic env vars to auto-generate the Postgres password and the Umami APP_SECRET. Practical human input is one field: the public domain.

From the Coolify UI:

Resources, New Resource, Service, Umami
Pick the project and environment
Set the public domain to analytics.dacforge.com
Deploy

Coolify issues the Let's Encrypt cert via Traefik. Postgres comes up alongside Umami in the same compose. Total elapsed: about five minutes, most of which is DNS propagation.

Log in to Umami at the public domain with the default admin / umami and change the password immediately. Add a website, note the generated data-website-id, and keep the browser tab open while you wire the script into the site.

Wiring the tracker into Astro

dacforge.com is a static Astro site rendered to HTML and served by nginx. The tracker is a single <script> tag in the shared Base.astro layout, gated behind a public env var so local builds do not report:

---
// src/layouts/Base.astro
const umamiSrc = import.meta.env.PUBLIC_UMAMI_SRC;
const umamiWebsiteId = import.meta.env.PUBLIC_UMAMI_WEBSITE_ID;
const umamiOrigin = umamiSrc ? new URL(umamiSrc).origin : null;
---
<head>
  {/* ... existing head ... */}
  {umamiOrigin && <link rel="preconnect" href={umamiOrigin} crossorigin />}
  {umamiSrc && umamiWebsiteId && (
    <script
      defer
      src={umamiSrc}
      data-website-id={umamiWebsiteId}
      data-do-not-track="true"
    />
  )}
</head>

Two details matter here. data-do-not-track="true" tells Umami's script to short-circuit on any browser that sends Do Not Track or Global Privacy Control. And the env-var gate means npm run dev on a laptop does not pollute the dashboard with a developer's own pageviews; only the production build, which has PUBLIC_UMAMI_SRC and PUBLIC_UMAMI_WEBSITE_ID set in Coolify, actually renders the script.

Deploy, open the site, open the Umami dashboard, watch the pageview count tick up by one. If it does not, the two usual suspects are a typo in the website ID or an ad blocker on your own browser (uBlock Origin blocks Umami's default script path; the workaround is to serve the script from your own domain, which the Coolify template already handles).

The `/privacy` page

A tracker without a privacy page is table stakes wrong. Before flipping the env vars, we rewrote /privacy to cover four things:

What we collect. Pageview, referrer, anonymised IP-derived country and city, user agent (device class, browser, OS). No cookies, no cross-site identifier, no profile join.
Legal basis. UK: the Data (Use and Access) Act 2025 statistical-purposes PECR exemption, which commenced on 5 February 2026. EU: GDPR Art. 6(1)(f) legitimate interest, bounded retention, no ad targeting. US: we honour Global Privacy Control and Do Not Track signals at the tracker level.
Retention. 13 months. Long enough to do year-over-year comparisons, short enough to bound the data. Umami's default is indefinite; the retention window is our add.
Opt-out. A visible toggle on the page that sets localStorage.umami.disabled = 1 and stops sending events from that browser. One click, no flow, no account.

We do not claim "no consent required, anywhere." The honest phrasing is "we rely on the UK DUAA statistical-purposes PECR exemption, on GDPR Art. 6(1)(f) legitimate interest in the EU, and we give you a one-click opt-out anyway."

What we ruled out

Plausible Community Edition. Shortest distance to a yes of any of the alternatives. It is cookieless, self-hostable, respected in the category. Three things tipped us away. AGPLv3's network-use clause is stricter than MIT for a studio that may fork or patch for client work. Practical RAM floor is ~1 GB with 2 GB recommended (ClickHouse is the cost) against Umami's ~512 MB; on a single Hetzner VPS that matters. And Plausible CE ships "twice annually" by explicit policy, gating funnels, SSO, Sites API, and advanced bot filtering to the cloud product. Coolify also does not ship a one-click for Plausible because of a trademark restriction, which pushes deploy time from five minutes to an hour of compose, SMTP, and port-override work.

GA4. Off the table for a privacy-positioned studio regardless of tooling. Third-party cookies, data leaves your infrastructure, consent banner required for most of the EU, and the regulatory blast radius is non-trivial. California's Capital One action in May 2025 (around $350k) targeted third-party pixels behind a broken consent UI; first-party cookieless counters on a site honouring Global Privacy Control are not the same category, but the GA-shaped risk is not one we are interested in carrying.

GoAccess. A log-based analyzer that reads nginx access logs and produces an HTML dashboard. Zero privacy cost, no client JS, no database. The reason it did not win is that it cannot see what a client-side tracker sees: no engagement time, no event funnels, no bounce-versus-read distinction. And it adds its own ops cost: a bind-mount from the nginx container, logrotate to coordinate with the real-time HTML refresh. GoAccess stays on the shortlist as a future sidecar for bot and bandwidth visibility, not a replacement for Umami.

Do-nothing. The version where we literally know nothing about visitor behaviour. Purest privacy posture available, and untenable past launch. We could not make page-investment or content decisions from zero data, and "no analytics" became the thing blocking useful ones.

If you want the same setup

The whole stack is one Hetzner box running Coolify, with nginx-served dacforge.com and Umami on the same host, Let's Encrypt via Traefik, Postgres per app. If you want a walk-through for your own site we offer a Coolify setup consultant engagement that covers the same ground end to end, and a DevOps consultant for small business engagement for the broader infra picture (boring infrastructure is a feature; it should not be somebody's side quest).

Or email hello@dacforge.com if you want to talk about shipping something together.

Per-page OG images on an Astro site, without the SaaS

DacForge — Fri, 17 Apr 2026 22:38:30 +0000

Every page on dacforge.com now has its own Open Graph image. The services hub has one image. Each of the ten service pages has its own. Each blog post has its own. The about page, the privacy page, and every other public URL on the site has a distinct card that shows up when someone pastes the link into LinkedIn, X, Mastodon, or Slack.

There is no Cloudinary account. No Vercel OG. No external image service. The whole thing runs at astro build, writes PNGs into dist/og/, and that is the last anyone thinks about it until a new page is added, at which point it just works.

Here is what the setup looks like and why it ended up smaller and more satisfying than any of the SaaS options we considered first.

Why per-page OG matters at all

If you do not care about the card that appears when someone shares your page in a messaging app or on social, you can skip this paragraph. If you do, consider what the alternative looks like. A single og-image.png at the root of your site means every URL you share shows the same card. The services page and the about page and the twelfth blog post all look identical. Anyone seeing three of your links in a feed immediately reads the repetition as "this person has a low bar for the surface of their work." Fixing it is the single biggest polish pass you can do on a static site in an afternoon.

The usual answer is one of three things: hand-design a PNG per page and remember to regenerate it every time the page changes, reach for Cloudinary's dynamic image transformations, or reach for Vercel OG. The first does not scale. The other two work, and they also add a third-party dependency that we are not sure we need for something this simple.

Four cards from the generator

Here are four of the cards the system produced on this site. Same template across all of them; each pulls its title, description, and eyebrow from the content collection the page belongs to.

Homepage · A SOFTWARE STUDIO eyebrow

Coolify Setup Consultant · TOOLING & AUTOMATION eyebrow · short title, one word per line

Custom Software Consultancy · BUILD eyebrow · longer title, two-line wrap, smaller type

Coolify setup lessons · BLOG eyebrow · blog post card

The eyebrow changes by section. The type size scales with the title length. The last word of the title gets rendered in the brand's vermillion accent (#ef5a38) on every card. None of this requires per-page configuration: the logic sits entirely in the renderer, and it reads from the site's existing content collection entries.

The build-time approach

DacForge is a studio that spends a lot of time arguing for self-hosted infrastructure for small teams. Pulling in a SaaS to draw the equivalent of a page title on a rectangle would be slightly embarrassing. The constraints we set were straightforward:

Generate every OG image at astro build time, not at runtime
No network call during the build
Fonts bundled in the repository so output is identical on any build host
One shared editorial template, so adding a new page requires no per-page manual work
Small enough in code size that it does not need a dedicated maintainer

Astro already supports dynamic endpoints that return binary responses. The Astro ecosystem also ships @resvg/resvg-js, a native rasteriser for SVG-to-PNG. Between those two things, every piece we need is already in the toolbox.

The endpoint

The whole system fits into one dynamic Astro endpoint. It lives at src/pages/og/[...path].png.ts. Its job is to enumerate every page that should have an OG image, then render one PNG per page at build time.

import type { APIRoute, GetStaticPaths } from 'astro';
import { getCollection } from 'astro:content';
import { renderOgPng } from '../../lib/og-image';

export const getStaticPaths: GetStaticPaths = async () => {
  const llm = await getCollection('llm');
  const posts = await getCollection('posts', ({ data }) => !data.draft);

  return [
    ...llm.map((entry) => ({
      params: { path: entry.data.path === '/' ? 'home' : entry.data.path.replace(/^\/|\/$/g, '') },
      props: {
        title: entry.data.title,
        description: entry.data.description,
        section: entry.data.section,
      },
    })),
    ...posts.map((post) => ({
      params: { path: `blog/${post.id}` },
      props: {
        title: post.data.title,
        description: post.data.description,
        section: 'Blog',
      },
    })),
  ];
};

export const GET: APIRoute = ({ props }) => {
  const png = renderOgPng(props as { title: string; description: string; section?: string });
  return new Response(png, {
    headers: { 'content-type': 'image/png', 'cache-control': 'public, max-age=3600' },
  });
};

Astro's getStaticPaths runs at build time. Each returned entry becomes a route. Each route writes a PNG into dist/og/{slug}.png. The browser never sees a template, an SVG, or a missing font. It gets a static image file from nginx, same as any other public asset.

The list of URLs is pulled from the existing content collections. Our llm collection holds the markdown mirrors of every public HTML page (a separate LLM-accessibility feature we already ship). Blog posts live in a separate posts collection. Together they cover every URL that should have a card.

The template

The rendering helper sits in src/lib/og-image.ts and has exactly one responsibility: given a page's title, description, and section, produce a PNG. The shape of the design is identical to the rest of the DacForge surface: a dark background, Instrument Serif for the display title with the last word in vermillion, JetBrains Mono for the eyebrow, a thin rule at the footer, the brand wordmark and URL anchored at the bottom corners. Nothing on the card is decorative; every element has a job.

Two things deserve a mention.

First, fonts are bundled in the repository and passed to @resvg/resvg-js via fontFiles. That makes the output font-independent. Whatever the build host has installed system-wide is ignored. This matters the first time you try to debug an OG image that looks different on your laptop versus in CI and realise that DejaVu Serif was quietly filling in where Instrument Serif should have been. With fonts pinned to the repo, the card is deterministic.

Second, the template picks a font size based on the title's length. Short titles (Coolify Setup Consultant) render at 140pt on one line. Longer titles (Custom Software Consultancy for Small Business) step down to 110pt and wrap to two. The longest edge cases step down again. The card never blows out its frame, never crunches against the footer rule, and the typography stays at visible weight at all thumbnail sizes.

The last word of the title gets rendered in the brand's vermillion accent (#ef5a38). This is the same move the DacForge homepage makes with the word software in the We build software tagline. Reusing that one design primitive makes every OG card on the site feel like it belongs to the same family without any per-page design effort.

Hooking it into the layout

The final piece is a one-line change in Base.astro, the shared layout for every page. Instead of hardcoding /og-image.png as the default meta image, the layout derives the per-page URL from the current pathname:

import { pathToOgSlug } from '../lib/og-image';

const derivedOgPath = `/og/${pathToOgSlug(Astro.url.pathname)}.png`;
const ogImageURL = new URL(ogImage ?? derivedOgPath, Astro.site).toString();

pathToOgSlug is five lines of string manipulation: strip leading and trailing slashes, treat the root as home, return everything else as-is. If a page passes an explicit ogImage prop, that wins. Otherwise the derivation takes over.

Tradeoffs

This is not the best approach for every site. A few honest caveats:

One template. We do not have per-page custom art. If your site needs genuinely hand-crafted imagery on each card, you will hit the limit of the shared design quickly. For a studio site that values consistency over expressive variation, that is a feature. For a magazine or a gallery, it is not.
Build time adds up. Rendering 18 PNGs at build takes about a second on this site. At several hundred pages the cost starts to matter. If you are shipping a large content site, caching at the build layer (or rendering only the pages that changed since the last build) is worth setting up.
Fonts in the repo. Instrument Serif, Inter, and JetBrains Mono live under scripts/fonts/ in the dacforge.com repo. That is a modest size increase (a few hundred KB) that we already accepted when we built the original static OG generator. If your site does not already bundle fonts, this is new surface area for you.
No runtime regeneration. Change a page title, you rebuild. For a static Astro site deployed through a normal CI flow, this is what happens anyway. For a CMS-driven setup where content changes without a rebuild, a runtime endpoint is a better shape.

Why not SaaS

Cloudinary and Vercel OG both work. For this one, the argument against them comes down to scope: we are drawing a page title on a rectangle. Adding a third-party dependency, an API key, a quota, and a new surface to monitor for a job that a short TypeScript file and a bundled font can handle is a mismatch. The self-hosted route also matches DacForge's general stance toward small teams: fewer moving parts, documented on your own disk, operable without calling someone else.

None of this is an argument against using a SaaS when it genuinely saves work. It is an argument for checking whether you actually need one before signing up.

If you are building on Astro and want the same shape, the source for this setup lives in the dacforge.com repository. The two files that matter are src/pages/og/[...path].png.ts and src/lib/og-image.ts. The rest is taste.

If you are running into self-hosted infrastructure questions more broadly, we offer a Coolify setup consultant engagement for teams that want production Coolify deployed properly, and a DevOps consultant for small business engagement for the broader infra picture.