Portable compiler v0.15.0
ZIP for Windows, macOS, and Linux. Requires Node.js 22 or newer. Includes the starter template generator and runtime.
Download portable ZIP ↓AMOOSEDWEB COMPILER · VERSION 0.15.0
Create an ordinary site and a second HTML, CSS, and JavaScript app. The compiler appends the second app to selected binary files, adds the site-owned runtime, and checks the resulting Pages package.
ZIP for Windows, macOS, and Linux. Requires Node.js 22 or newer. Includes the starter template generator and runtime.
Download portable ZIP ↓Install the locally packaged CLI with npm. This tarball is hosted here; it has not been published to the npm registry.
Download npm tarball ↓Extract the ZIP and load its folder in Chrome at chrome://extensions/ with Developer mode and Load unpacked.
The portable ZIP and npm tarball contain the same compiler version. Native executables are built for their host operating system and are not in this Pages download set. Plain-text README.
Extract the portable ZIP, keep runtime/ beside amw.cjs, and run:
node amw.cjs init my-siteOn Windows you can use amw.cmd; on macOS or Linux use sh amw.sh. To use npm instead, download the tarball and run npm install -g ./amoosedweb-cli-0.15.0.tgz, then use amw in the commands below. The new folder is its own Git repository.
Edit my-site/site/ for the normal website and its existing binary media. Edit my-site/app/ for Amoosed mode. The starter already has a public Hello World app and an encrypted members/ page. document.json controls the small boot introduction; bundle.json lists carrier paths and protected resources. Read my-site/README.txt for the project-specific walkthrough.
cd my-site
build.cmd (Windows)
sh build.sh (macOS/Linux)Use the command for your operating system. The helper creates and verifies a fresh builds/local-NNNN/ folder. Run amw serve builds/local-0001 with the path it prints, then open the local address in Chrome. The first successful build creates a private members key under .amw/keys/; keep it out of Git and the public site.
release.cmd YOUR_PAGES_PROJECT (Windows)
sh release.sh YOUR_PAGES_PROJECT (macOS/Linux)This packages and verifies a fresh distribution/release-NNNN/pages/ without uploading. The adjacent DEPLOY.txt gives manual Wrangler steps. The compiler saves a source and key snapshot outside the upload. Use publish.cmd or sh publish.sh to package and upload in one guided run.
Commit or stash project changes, install the newer compiler, then run amw update-project my-site. It updates unchanged starter files and preserves customized files. Review and commit the project diff, then build a new distribution. Never edit generated carrier bytes or pages/ files by hand.
From inside your generated project, run publish.cmd YOUR_PAGES_PROJECT on Windows or sh publish.sh YOUR_PAGES_PROJECT on macOS/Linux. The helper builds a new verified release, checks its private backup, lists your Cloudflare Pages projects, opens Wrangler login if needed, and offers to create the project if it is absent. It then deploys only the verified pages/ folder. You choose when to run it; building or making a release never deploys.
cd my-site
publish.cmd my-pages-project (Windows)
sh publish.sh my-pages-project (macOS/Linux)For an existing Pages project whose production branch differs from your Git branch, add it as the last argument, for example publish.cmd my-pages-project main. Wrangler may ask you to authorize Cloudflare in a browser. Choose Y when your project appears in the list or N to create it. Set your custom domain in the Cloudflare Pages dashboard after deployment. Keep .amw/, DEPLOY.txt, and the distribution manifest off the site. Test the deployed favicon, carrier bytes, app route, and downloads yourself; image optimization that rewrites carriers breaks the content. Cloudflare’s Direct Upload guide ↗
The starter creates these editable paths. site/ holds the normal website and original binary media; app/ holds the second website; document.json holds the short boot introduction. The compiler-created .amw-template.json is an upgrade record and should stay in Git without hand editing. .amw/, public/, and distribution/ are ignored or generated.
A typical bundle.json looks like this:
{
"document": "document.json",
"carriers": ["media/scene.png", "media/another-photo.jpg"],
"chunkSize": 65536,
"keyId": "friends-1",
"protected": ["members/"]
}Carrier paths are relative to site/ and must name binary files already present there. Add more carriers to distribute a larger app. chunkSize controls the maximum app chunk size. keyId names the protected edition, and protected names app paths requiring its private content key. Leave protected resources out if the whole app is public. Add "indexDelivery":"external" when the app itself needs a separately shared index key. Rebuild into a fresh output folder after changing any of these values.
Put your existing static build in site/, keep its normal pages and media, place the alternative app in app/, and list the exact existing carrier paths in bundle.json. The compiler modifies the selected binary files and adds the /amoosed.com/ boot and service-worker routes. Full app mode requires those origin-owned routes. Hosts must serve carrier bytes without recompression or stripping and support byte ranges for large files. WordPress needs a route adapter; the static Pages folder is not a drop-in WordPress plugin.
The public site can have a member-only area, but a shared key can be forwarded and already downloaded content cannot be revoked. Read the generated project README before distributing a key.
List existing image, video, or other opaque binary paths in bundle.json. The compiler splits app files into chunks across those carriers, appends them without changing the original prefix, and writes a versioned index. The ordinary site continues to serve its own pages and media. Carrier URLs and bytes must remain stable; an image optimizer that rewrites a file can remove the appended data.
The extension’s side panel is an Amoosed-owned mode switch, key entry, and optional diagnostics surface. It never runs your app UI. The boot route loads and verifies chunks, then opens the full app at /amoosed.com/app/ on the website’s own origin. Full HTML, CSS, JavaScript, images, WASM, and downloadable files belong in app/.
The default starter serves a public Hello World page and protects app/members/. The protected paths in bundle.json select resources encrypted with a separate members key. The first successful build generates that key privately in .amw/keys/. Anyone with the public index can recover public app code; packaging and minification do not make it secret.
Normally the favicon carries the index and a public decoding key, so visitors with the extension can discover Amoosed mode. For a private entry, set "indexDelivery":"external" in bundle.json. The ordinary favicon stays unchanged; the compiler writes an encrypted index into a selected carrier and creates a private .amwkey plus compatible .ico file outside the site build. Share one of these only with intended visitors.
For an externally indexed site, the generated .amwkey or private ICO is a bearer key to that app release. The recipient opens the normal website and imports it from the Amoosed boot page. To make a scannable invitation, run:
amw key-link my-site/.amw/indexes/key-<digest>.amwkey https://your-site.example/ invitation.svgThe command writes an SVG QR and prints an HTTPS boot URL. The QR contains the site URL, encrypted-index locator, and key in the URL fragment. The fragment is not sent with the HTTP request; the page verifies it against the carrier before storing it for that site in browser storage.
Members can instead receive a separate .amwmember file or member QR. The starter creates the file under .amw/keys/. A members QR targets one protected app path:
amw member-link my-site/.amw/keys/hello-members.amwmember https://your-site.example/ /amoosed.com/app/members/index.html member.svgUse amw rotate-project my-site members to replace the members key, site for the site-wide key, or both for both. Rebuild into a new output folder, publish the new index and all changed carriers together, and distribute the new credential. In hosted-index mode the site-wide key is public encoding, so rotating it alone does not revoke access. Previously copied keys, plaintext, or complete old releases cannot be recalled.
You can put an invitation QR on a card, poster, or object and publish only the encrypted carrier files online. A person who has the physical QR can scan it to obtain the matching key and open the private Amoosed edition. The host need not run a membership server or collect identities. A separate members QR can unlock only the protected part after the app index is available.
A QR is a copyable bearer credential. Anyone who photographs, forwards, or posts it can share the same access. Use a public event poster only when everyone who sees it may enter; use a private card or direct message for a smaller audience. A shared key cannot prove who scanned it, enforce one person per key, or stop recipients saving decrypted content. This is useful for consent-based sharing and lightweight access control, not DRM.
The URL fragment normally stays out of the host’s HTTP request, but the scanner app, browser history or sync, screenshots, clipboard, and same-origin scripts may still expose it. After verification the site-owned browser runtime stores the key for that origin; the Amoosed side panel does not copy the member key into extension storage. The website and CDN can still see visits and may keep normal access logs. If you need stronger privacy, distribute the QR carefully, avoid third-party scripts on the site, use HTTPS, and publish a new key and carrier release when rotating access.
amw init DIRamw init-share DIR FILE [FILE...]amw build-project PROJECT OUTamw serve DIRamw verify-site DIRamw package-pages PROJECT DISTRIBUTION NAMEamw verify-managed DISTRIBUTIONamw verify-backup DISTRIBUTIONamw deploy-pages DISTRIBUTION NAMEamw update-project PROJECTamw rotate-project PROJECT members|site|bothamw key-link KEY.amwkey SITE_URL [QR.svg]amw member-link KEY.amwmember SITE_URL PROTECTED_PATH [QR.svg]The compiler also has lower-level bundle, verify-bundle, unpack-bundle, pack, and unpack commands for integration with an existing build pipeline. Run amw --help for their exact arguments.