Packaging and Deployment #

A Budo app starts as a folder, but the same folder can be run locally, exported to a static web build, or packaged as an Android APK or AAB. The packaging tools read the same entrypoints, project-relative assets, and app.json metadata used by the runtime.

Local desktop runs #

Use run while developing.

# Run one of the bundled examples on desktop.
budo run examples/demo
# Run your app with an explicit window size and title.
budo run my-app --width 1280 --height 720 --title "My App"

The implicit shorthand also works:

# Use the shorthand form when you only want to run a project.
budo my-app

Useful run options include --fullscreen, --no-vsync, and --file-root <path>. --file-root changes the sys.files virtual files/ mount on desktop without changing its assets/ mount, the sys.assets convenience wrapper, or project-relative loaders such as shaders and fonts.

Project bootstrap #

init writes a starter project into the target directory.

# Create a starter project with metadata and editor helper files.
budo init my-app

It creates main.js, app.json, jsconfig.json, a copy of the developer API reference, and TypeScript declarations. This is the quickest way to get editor autocompletion for the runtime globals.

Web export #

An option to run your application is to package it for the Web. In this case, the web-export command will export your application as a static html/css/js content that you can integrate in any Web page. And the web-serve command launches a small HTTP server to serve your application from your computer.

The web target packages a self-contained static folder with the Emscripten runtime and your project assets.

# Export a self-contained static web folder.
budo web-export my-app -o dist/my-app-web

To serve locally:

# Serves your application as a local website 
budo web-serve DIRECTORY

Web builds use QuickJS and Lua compiled through Emscripten. Raw UDP and RTP-MIDI are unavailable on web because browsers do not expose UDP sockets.

Android packaging #

Budo Pro: Android APK/AAB packaging is a paid feature. Public builds keep these commands visible, but require the private Android feature pack under private/android before packaging is enabled.

To package your application for Android, you can use the android-apk command. It will produce an .apk file that you can upload on your device with adb. The andoid-aab command produces a signed Android .aab file that is directly usable in the Google Console.

Android packaging is driven by the desktop budo binary.

# Build a debug APK for local testing.
budo android-apk my-app
# Build a release APK.
budo android-apk my-app --release
# Build a release Android App Bundle for store delivery.
budo android-aab my-app --release

Use --install with android-apk to install the produced APK on connected adb devices.

# Build and install the APK on connected adb devices.
budo android-apk my-app --install

The packager applies identity and release metadata, bundles the selected app's runtime assets, and writes the final APK/AAB to dist/ by default. Temporary paths and generated files are implementation details, not stable API.

Android metadata #

Budo Pro: These metadata fields are consumed by the paid Android packaging feature.

The same app.json used by your app can carry Android release details.

{
  "name": "Pulse Orbit",
  "package_name": "com.example.pulseorbit",
  "version_name": "1.0.0",
  "version_code": 1,
  "orientation": "portrait",
  "fullscreen": true,
  "icon": "icon.png",
  "network": ["api.example.com"],
  "filesystem": false,
  "permissions": ["INTERNET"]
}

Fields are optional, but release packages should set a stable package identifier and version code. Icons may be PNG or SVG depending on the packaging path and available tooling.

The packager skips packaging metadata that should not become runtime assets, including store listing folders, icon source files used for generation, and keystore files.

Signing and release builds #

Debug builds use the normal Android debug signing flow. Release builds need release signing configuration. Keep signing material outside the runtime asset set and outside source control.

The Android packaging helpers can read signing-related metadata from app.json. For Play Store delivery, prefer android-aab --release once you have verified the APK locally.

Store listing scaffolding #

Apps can include store listing metadata and media beside their project files. The packager can prepare Play Store listing scaffolding while keeping that material out of the runtime asset bundle.

This is useful for examples such as games that ship with screenshots, feature images, privacy pages, and localized descriptions.

Build prerequisites #

Desktop builds require CMake, a C and C++ compiler, SDL2, Skia, and platform libraries such as FreeType, Fontconfig, OpenSSL, and ALSA where applicable. CMake fetches QuickJS, Lua, Wasmtime, SQLite, and several pinned dependencies during configuration.

Android builds require the private Budo Pro feature pack, the Android SDK and NDK, Android-ready native dependencies prepared by the Pro setup flow, and a rebuilt desktop Budo binary. ONNX Runtime Android support is prepared separately when neural inference is enabled for Android.

Web builds require an activated Emscripten SDK and the Skia-WASM setup used by the web/ CMake project.

Release checklist #

Before shipping, run the app on every target you claim to support. Check capability branches, asset paths, network policy, file policy, shader compilation, display density, touch ergonomics, audio start behavior, and package metadata.

For Android, test both debug and release artifacts. For web, serve the exported folder over HTTP rather than opening it directly from the filesystem; browser security rules are different under file://.