Whitepaper: ueo.ventures - eine einseitige statische Website gehostet bei DownToZero

Dieses Whitepaper veranschaulicht, wie DownToZero zum Hosting einer statischen Website verwendet wird. Wir geben Einblicke, wie die Website aufgebaut wurde, und präsentieren reale Daten zur Nutzung sowie deren Auswirkungen auf die DownToZero-Nutzung und damit die Kosten.

What Is ueo.ventures?

ueo.ventures ist eine statische Seite, die externen Stellen Zugangsdaten bereitstellt. Die Seite ist sehr minimalistisch und besteht nur aus 2 statischen Seiten. Sie beinhaltet:

  • Startseite – mit dem Namen des Unternehmens
  • Impressum-Seite – mit den rechtlichen Angaben für ein privates Unternehmen

How is it build?

Wie bereits erwähnt, enthält die Website nur 2 Seiten. Diese Seiten sind statische Dateien in einem GitHub-Repository. Um diese DownToZero zur Verfügung zu stellen, müssen wir diese zwei Dateien als Docker-Container verpacken.

Hier das komplette Dockerfile, das für das Verpacken der Website verwendet wird.

FROM alpine AS runner
RUN apk add --update --no-cache lighttpd && rm -rf /var/cache/apk/*
ADD index.html /var/www/localhost/htdocs/
ADD impressum.html /var/www/localhost/htdocs/
CMD ["/usr/sbin/lighttpd", "-D", "-f", "/etc/lighttpd/lighttpd.conf"]

Und die Pipeline, mit der wir die jeweils aktuellste Version bauen und bereitstellen.

name: website
on:
  push:
  workflow_dispatch:
  schedule:
    - cron: '30 5 25 * *'
jobs:
  build-website:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: build website
      run: |
        docker build -t xb35e5d0.cr.dtz.dev/ueo-ventures .
    - name: Login to xb35e5d0.cr.dtz.dev
      uses: docker/login-action@v3
      with:
        registry: xb35e5d0.cr.dtz.dev
        username: apikey
        password: ${{ secrets.DTZ_API_KEY }}
    - name: uploading image to xb35e5d0.cr.dtz.dev
      run: |
        docker push xb35e5d0.cr.dtz.dev/ueo-ventures:latest
    - name: Resolve image digest
      id: resolve_digest
      run: |
        DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' xb35e5d0.cr.dtz.dev/ueo-ventures:latest)
        echo "IMAGE_URL=$DIGEST" >> $GITHUB_ENV
    - name: Deploy latest image to service
      uses: DownToZero-Cloud/containers-service-update@main
      with:
        container_image: ${{ env.IMAGE_URL }}
        api_key: ${{ secrets.DTZ_API_KEY }}
        service_id: service-e1d1efd8
    - name: Publish image URL to summary
      run: |
        echo "## Deployed image" >> $GITHUB_STEP_SUMMARY
        echo "" >> $GITHUB_STEP_SUMMARY
        echo "${IMAGE_URL}" >> $GITHUB_STEP_SUMMARY

How much is it used?

requests

Die Anzahl der Zugriffe auf diese Seite ist relativ gering. Daher sehen wir viele nicht optimierte Cold-Starts. Das Gesamtvolumen pro Tag liegt im Durchschnitt bei etwa 200 Anfragen.

Hier ein kurzer Beispieldatensatz

day requests
2025-09-12 147
2025-09-13 116
2025-09-14 118
2025-09-15 121
2025-09-16 200
2025-09-17 169
2025-09-18 157
2025-09-19 268
2025-09-20 524
2025-09-21 496
2025-09-22 228
2025-09-23 246
2025-09-24 123
2025-09-25 79
2025-09-26 60

splitting the request by cold-starts

Cold Starts sind Starts, bei denen nichts auf dem ausführenden Host vorhanden ist. Warm Starts sind Starts, bei denen das Image bereits auf dem ausführenden Host geladen ist, der Container aber noch gestartet werden muss. Hot Starts sind Starts, bei denen der Container bereits läuft.

day cold starts warm starts hot starts
2025-09-12 63 48 14
2025-09-13 70 3 21
2025-09-14 61 3 22
2025-09-15 68 0 31
2025-09-16 84 3 27
2025-09-17 53 3 25
2025-09-18 72 2 27
2025-09-19 48 2 19
2025-09-20 501 2 10
2025-09-21 474 3 1
2025-09-22 199 3 2
2025-09-23 201 3 27
2025-09-24 71 5 31
2025-09-25 51 3 20

response times

Während der Unterschied zwischen Hot- und Cold-Starts in relativen Werten deutlich erscheint, unterschreitet die gesamte Cold-Start-Zeit nicht 3 ms.

Latenz-Perzentile in ms

state p50 p90 p95 p99
cold 0.536 1.003 2.0888 3.2584
hot 0 0 0.001 0.001

Power Consumption

All dies spiegelt sich in einem bestimmten Nutzungs-Typ und -Muster wider. Unsere Metrik zur Bestimmung der Nutzung ist Watt. Wir messen den Energieverbrauch für alle Aktivitäten und liefern detaillierte Statistiken über die Zeit.

| day | power consumption (in Wh) | | — | ———– :| | 2025-09-12 | 1.88 | | 2025-09-13 | 2.00 | | 2025-09-14 | 0.96 | | 2025-09-15 | 1.76 | | 2025-09-16 | 3.14 | | 2025-09-17 | 0.43 | | 2025-09-18 | 1.90 | | 2025-09-19 | 1.06 | | 2025-09-20 | 4.74 | | 2025-09-21 | 4.51 | | 2025-09-22 | 1.62 | | 2025-09-23 | 6.51 | | 2025-09-24 | 3.85 | | 2025-09-25 | 3.29 | | 2025-09-26 | 2.81 |

Pricing & Cost Efficiency

DownToZero verrechnet Compute ausschließlich nach verbrauchter Energie. Die aktuellen Tarife sind:

  • Compute: 0,010 EUR pro Watt-Stunde (Wh) im Normalmodus; 0,005 EUR/Wh im EcoMode.
  • Storage: Hot Storage – 0,0013 EUR / GB / Tag; Cold Storage – 0,0007 EUR / GB / Tag.

Basierend auf dem gemessenen Verbrauch des ueo.ventures-Dienstes:

  • Requests: ~203 Anfragen/Tag im Durchschnitt über den Beobachtungszeitraum (Spitze 524; Minimum 60).
  • Energie: ~2,40 Wh/Tag im Durchschnitt (Minimum 0,43 Wh; Maximum 6,51 Wh).

Geschätzte Compute-Kosten bei aktuellen Tarifen:

  • Normalmodus: ~0,024 EUR/Tag (~0,72 EUR pro 30-Tage-Monat); Tagesbereich ca. 0,004–0,065 EUR.
  • EcoMode: ~0,012 EUR/Tag (~0,36 EUR pro 30-Tage-Monat); Tagesbereich ca. 0,002–0,033 EUR.

Da pro Watt abgerechnet wird, besteht ein direkter Anreiz, Images schlank zu halten, unnötige Arbeit bei Cold-Starts zu vermeiden und EcoMode zu nutzen, wo praktikabel. Im Laufe der Zeit kann dies sowohl Ausgaben als auch Energieverbrauch reduzieren.

Trade-offs: EcoMode kann andere Performance-Charakteristika mit sich bringen (z.B. Startlatenz, Scheduling); Kosten können bei Nutzungsspitzen schwanken. Verbrauch überwachen und bei Bedarf anpassen.