Skip to main content
Every way of running AppBlips gives you your own copy for a single user: the desktop app, the browser version from source, and Docker. This page explains the security boundaries that matter in each.

​
The desktop app stays on your computer

  • The desktop app has no sign-in and opens no network port, so other devices can’t reach it or use your API key.
  • The apps you build, and web pages from other sites, can’t use AppBlips to call your AI provider.
  • Set a spend limit with your AI provider. Your own copy of AppBlips doesn’t limit how many requests it sends, so a runaway app could otherwise run up costs.

​
Browser and Docker versions

The browser version (npm start) and Docker run a small web server on your computer. Like the desktop app, it has no sign-in, so it’s set up to answer only you:
  • It listens on 127.0.0.1 (Docker publishes it as 127.0.0.1:3000), so other devices on your network can’t connect.
  • It only answers when opened as localhost, 127.0.0.1 or [::1]. This stops a website from pointing its own domain name at your computer to reach AppBlips.
  • Like the desktop app, it refuses AI requests from other websites and from the apps you build.
If you make AppBlips reachable from other devices (by changing HOST, removing 127.0.0.1: from docker-compose.yml, or adding names to APPBLIPS_ALLOWED_HOSTS), anyone who can reach it can spend an API key set in .env and use the server to send requests on your behalf. Put your own sign-in in front of it first, for example a reverse proxy with authentication.

​
Your API key

  • Desktop app: your provider key is encrypted with your system keychain and used only by the app’s background process. It is never sent to the app’s web page.
  • Browser and Docker versions: a key entered in Settings → AI is sent once to AppBlips’ own server, which saves it in a file only your user account can read (provider-key.json in .appblips in your home folder, or in the appblips-data volume for Docker). The server adds it to each request to your provider. It is never saved in your browser, and the page can’t read it back. A key in .env also stays on the server. Your Surge sign-in for Publish to the web is kept the same way, in surge-token.json, as are the Pollinations sign-in (pollinations-key.json) your Pixabay key (pixabay-key.json) and your Tavily key (tavily-key.json). AppBlips 0.1.7 and earlier kept the key in the browser; the first time you open a newer version, it moves the key to the server and deletes it from the browser.
In every version, the key is never embedded in generated app code and never included in exported HTML.

​
Sandboxed preview

Generated apps never run directly inside the main AppBlips page. Every generated app runs in an isolated preview, which means:
  • The generated app cannot access the parent page’s DOM, cookies, or localStorage
  • The parent page cannot reach into the generated app’s DOM
  • The generated app cannot use your API key or call your AI provider through AppBlips
Open in new tab uses the same isolation: the tab shows a small AppBlips page with your app inside an isolated frame. Whatever the app saves while open in that tab is kept for that tab only. This isolation is the main protection against malicious or buggy generated code affecting AppBlips itself.

​
Microphone

Voice input records the microphone only while you have it switched on with the microphone key, and turns it into text on your computer. The recording is never uploaded or saved.
  • In the desktop app, only AppBlips’ own screen may use the microphone, and only for sound. The preview, where generated apps run, is refused, and nothing may use the camera.
  • In the browser version, the preview has no permission to use the microphone either.

​
The speech model

The speech model (OpenAI’s Whisper base) is part of AppBlips itself, not something it fetches while running:
  • The desktop app includes it in the installer.
  • When you build from source or with Docker, the build downloads it once from Hugging Face. It always downloads one fixed version and checks each file against a fingerprint (a SHA-256 hash) stored in AppBlips’ code. If a file has been changed, the build stops with does not match its pinned sha256 instead of using it.
  • While AppBlips runs, it is set to load the model only from its own files. If they are missing, voice input shows an error rather than downloading a model from the internet.
  • The model and the code that runs it come from AppBlips’ own server or app files, not from a CDN (a public site that hosts code), so using voice input makes no network requests.

​
Opening exported apps

Exported apps are self-contained HTML with full script privileges. Open or host them separately from AppBlips (for example, as a local file or on a different domain) rather than serving them from the same origin as AppBlips, so an app can’t read what AppBlips stores in the browser.