Blog

Build a website app with Pake on GitHub Actions

Build an app · October 17, 2026 · 6 min read

Fork tw93/Pake, open Actions, run Build App With Pake CLI with your website address and an app name, then download the app from the run's Artifacts section. You need no local Rust toolchain. Download it within three days, because this workflow keeps its artifacts only that long.

What the workflow actually does

The workflow is defined in Pake's repository as .github/workflows/pake-cli.yaml. When you click Run workflow, GitHub starts a fresh virtual machine of the type you chose, checks out your fork, installs Node.js and pnpm, builds the Pake CLI, and then runs it with the values from the form, roughly node dist/cli.js <url> --name <name> plus the optional flags. The packaged app is uploaded as a workflow artifact. Nothing is installed on your computer and nothing is written to your repository, and the workflow asks for read-only repository permission.

That explains the two limits you hit first. The runner is a machine in GitHub's data center, so it can only reach what the public internet can reach: localhost means the runner, and a private intranet address may be unreachable. And the form takes a website URL, so there is no way to hand it local files from your disk; for those see packaging local HTML.

Run your first build

1. Fork tw93/Pake into your own account. Open the Actions tab of the fork and enable workflows if GitHub asks.
2. Select Build App With Pake CLI in the left list, then open Run workflow.
3. Fill in the form. These are the inputs defined in the workflow file:

1. Click Run workflow, open the new run and wait for the build and the upload step to finish.

For a first test, leave everything beyond platform, URL and name at its default. The workflow reference shows the form, and every option behind it is explained in the CLI options.

Expect a long first run. Pake's guide gives about 10 to 15 minutes for the first run, which builds the dependency cache, and about 5 minutes for later runs, with a cache of 400 to 600 MB. Each build step also has a 25 minute timeout in the workflow file.

Download the artifact, not the repository archive

When the run shows a green check, open its summary and find Artifacts. The names come from the workflow: <name>-macOS holds a DMG, <name>-Windows holds an MSI, and on Linux you get separate artifacts such as <name>-Linux-deb and <name>-Linux-AppImage. Download the one for your system and unzip it, since the upload step zips each artifact.

Two details are easy to miss. Reading a workflow's artifacts requires read access to the repository, which you have in your own fork (GitHub's guide). And although GitHub's default retention is 90 days, this workflow sets retention-days: 3, so a run you come back to on Friday may have nothing to download. Save the file you need straight away, or run it again.

The same guide notes that you can use gh run download RUN_ID from the command line if you prefer.

What a green run does and does not prove

A green check means Pake built and uploaded a package. It does not show that the site's sign-in works inside an embedded web view, that the app suits your CPU architecture, or that it is signed and notarized for distribution. Check the downloaded package’s signing and notarization status, and test it on the target system. Google and some other providers may refuse sign-in in embedded views whatever the flags (sign-in guide).

Use Pake Action in your own repository

If you want packaging inside your own project's build, the repository also publishes Pake Action. A minimal workflow looks like this:

name: Build Web App
on: [workflow_dispatch]

jobs:
  build:
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: tw93/Pake@v3
        with:
          url: "https://example.com"
          name: "MyApp"

Its inputs are url, name, output-dir (default dist), icon, width, height and debug, and it reports the result as package-path. Output differs from the form workflow: on macOS it produces an .app bundle, on Windows an .msi, and on Linux a .deb, .rpm or .AppImage. Each run moves the single package the CLI wrote into the output directory, and the step fails if two packages of the same format turn up (Pake Action). Add your own actions/upload-artifact step to keep the files, and choose its retention yourself.

When a run fails

Open the first failed step and read its error before rerunning. The usual causes differ, and each needs its own fix:

• A mistyped or unreachable URL, or a private address. Use the public address.
• An icon URL that cannot be fetched. Leave it empty or use a reachable image.
• A dependency or toolchain failure early in the log. Rerun once, then check the Pake FAQ for your platform.
• Everything stops before any step runs. That points at the account, such as Actions usage blocked by billing, not at Pake.

The workflow guide suggests clearing the Actions cache and retrying when a build fails. Do that after you have a reason to blame the cache, not as the first step.

When another route is better

Actions is a good fit for a public site on a platform you do not have at hand. For ordinary Mac or Windows apps, the desktop app needs no compiler either, and a local install of Pake CLI is faster once its first build is cached.

FAQ

Do I have to fork the repository?

You run the workflow from a repository you control, and the simplest way is a fork of tw93/Pake with Actions enabled. Pake Action lets you do it from any repository.

Can I build for Apple silicon and Intel?

Tick Universal binary (macOS only) on the form. Without it the build is not universal, and the CLI documents that it detects the architecture it builds for.

Where is the Windows installer?

In the <name>-Windows artifact, as an .msi.

Can I build local files this way?

No. The form takes a website URL. Use Pake CLI locally for files on disk.