Whitepaper: ueo.ventures - a single page static website hosted at DownToZero

Dieses Whitepaper zeigt, wie DownToZero zum Hosten einer statischen Website verwendet wird. Wir geben Einblicke, wie die Website aufgebaut wurde, und liefern einige reale Nutzungsdaten, wie sie verwendet wird und wie sich das in der DownToZero-Nutzung und damit in den Kosten widerspiegelt.

What Is ueo.ventures?

ueo.ventures ist eine statische Seite, die Zugangsdaten für externe Stellen bereitstellt. Die Seite ist sehr minimal und besteht nur aus 2 statischen Seiten. Sie umfasst:

  • Startseite (index) - nennt den Namen des Unternehmens
  • Impressum-Seite - enthält die rechtlichen Anforderungen für ein Privatunternehmen

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 dies DownToZero zur Verfügung zu stellen, müssen wir diese beiden Dateien als Docker-Container verpacken.

Hier ist das vollständige Dockerfile, das verwendet wurde, um die Website zu verpacken.

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, die wir verwenden, um die aktuellste Version zu bauen und bereitzustellen.

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 Anfragen an diese Seite ist relativ gering. Daher werden wir viele unoptimierte Cold-Starts sehen. Das tägliche Volumen liegt im Schnitt bei etwa 200 Anfragen pro Tag.

Hier ein kurzes Beispielset

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, wenn das Image bereits auf dem ausführenden Host geladen ist, aber der Container gestartet werden muss. Hot-Starts sind, wenn der Container bereits hochgefahren und aktiv ist.

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 sich der Unterschied zwischen Hot- und Cold-Starts in relativen Werten signifikant zu zeigen scheint, fällt die absolute Cold-Start-Zeit nicht unter 3 ms.

Latency Percentiles 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 übersetzt sich in einen bestimmten Nutzungstyp und ein Nutzungsmuster. Unsere Kennzahl zur Bestimmung des Verbrauchs ist Watt. Wir messen den Energieverbrauch für alle diese 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 berechnet Compute ausschließlich nach verbrauchter Energie. Aktuelle 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 der gemessenen Nutzung dieses ueo.ventures-Dienstes:

  • Anfragen: ~203 Anfragen/Tag im Durchschnitt über den Stichzeitraum (Spitze 524; Minimum 60).
  • Energie: ~2.40 Wh/Tag im Durchschnitt (min 0.43 Wh; max 6.51 Wh).

Geschätzte Compute-Kosten zu den aktuellen Tarifen:

  • Normalmodus: ~0.024 EUR/Tag (~0.72 EUR pro 30-Tage-Monat); tägliche Spanne ≈ 0.004–0.065 EUR.
  • ecoMode: ~0.012 EUR/Tag (~0.36 EUR pro 30-Tage-Monat); tägliche Spanne ≈ 0.002–0.033 EUR.

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

Trade-offs: ecoMode kann andere Leistungsmerkmale mit sich bringen (z. B. Start-Latenz, Scheduling); die Kosten können bei Nutzungsspitzen variieren. Überwachen Sie den Verbrauch und passen Sie bei Bedarf an.