Building a Website Entirely on Android

A modern website can involve a remarkable quantity of machinery before it displays a paragraph and a photograph. This one deliberately does not.

The problem

The desired publication is simple: text, photographs, diagrams and a growing archive of observations. None of those things inherently requires a database, content-management system, permanent server, JavaScript framework or monthly software subscription.

The more interesting constraint was that the whole publication should be practical to build and maintain from an Android phone.

The principle

Separate the workshop from the publication.

The workshop is a directory of ordinary files under Git. Markdown contains the writing. Images remain images. CSS controls the printed appearance. Git records what changed and when.

Hugo takes those source files and builds a disposable public/ directory of static HTML. Cloudflare serves that output. If the generated site disappears tomorrow, it can be rebuilt from the repository.

Nothing important lives only in an admin panel.

The chain

ANDROID PHONE
     ↓
TERMUX
     ↓
MARKDOWN + CSS + IMAGES
     ↓
GIT
     ↓
GITHUB
     ↓
CLOUDFLARE BUILD
     ↓
HUGO
     ↓
STATIC HTML
     ↓
CLOUDFLARE WORKER STATIC ASSETS

The phone is a tool, not the server. Once a commit has been pushed, the phone can be switched off and the site remains online.

The Android workstation

Termux provides a small Linux environment on Android. The essential toolset is equally small:

Git          version control and transport
Hugo         static-site generator
Nano         text editor
ImageMagick  image preparation and dithering
Unzip        moving packaged site revisions into place

The working repository lives inside Termux home rather than Android shared storage. Downloads and camera files enter through shared storage, then move into the repository when they become part of the publication.

That distinction avoids a surprising number of permission and filesystem irritations.

Git as the permanent workshop

Git is more valuable here than any CMS. It keeps the source human-readable, records the history and makes publishing a consequence of a commit rather than a separate editorial ritual.

The normal publication sequence is:

git status
git add .
git commit -m "Describe the change"
git push

That push is the publish button.

Hugo as a compiler

Hugo is treated less like a website product and more like a compiler. It reads the archive and assembles indexes, place pages, tags, RSS feeds, navigation and relationships between records.

The output is intentionally boring: HTML, CSS, a few bytes of JavaScript and images.

Boring formats are excellent archival technology.

Cloudflare as delivery, not dependency

Cloudflare pulls the Git repository, builds the site with Hugo and deploys the public/ directory as Worker Static Assets.

The first live build used Hugo 0.164.0 and the following commands:

BUILD   hugo --minify
DEPLOY  npx wrangler deploy

Wrangler is told only that ./public contains the assets. There is no application server hiding behind the site.

The failures were useful

The first local Hugo build failed because Git metadata had been enabled before the repository contained its first commit. The fix was not a plugin or a package: initialise Git, make the first commit, build again.

The first GitHub push failed because a placeholder remote URL was still configured. The next failed because an HTTPS credential lacked repository write permission. Both errors were visible, specific and repairable.

The Worker then deployed correctly while the phone’s browser claimed the hostname did not exist. Direct DNS queries resolved it; the system resolver did not. Changing the phone’s DNS path produced an HTTP/2 200 response immediately.

A small stack makes faults easier to locate because there are fewer places for them to hide.

Measurement

The initial Hugo publication assembled dozens of pages in well under a tenth of a second. That number will grow, but build speed is not the main point. The useful measurement is conceptual: how much machinery must remain alive for an old page to continue existing?

For a static page, remarkably little.

What actually matters

The technical trick is not running Hugo on a phone. The useful result is ownership of the archive.

A field note written in 2026 should not require the survival of an account dashboard, database schema, proprietary editor or subscription plan to remain readable in 2036.

The source should still look like writing and photographs on a filesystem.

That is the system being built here.