# Publish to the web

Check whether an app can run as a public website, then prepare and manage its deployment.

Source: https://appjuice.app/guide/publishing/
Updated: 2026-09-14
Guide baseline: AppJuice 0.350.4

## Choose the appropriate kind of sharing

Remote Access: Approved browsers use apps still running on your host.
Juicery or ZIP: Another person installs an app into their own AppJuice environment.
Web publishing: An eligible app is deployed to a hosting provider and used through a public web address.

Publishing can expose app content and accept visitor data. It also introduces hosting requirements and potential provider costs.

## Configure Publishing

Open Settings → Publishing to configure the supported hosting connections. Cloudflare is used for eligible static apps. Railway is used for eligible apps that need a standalone Node backend, persistent storage, or WebSockets.

Complete the connection or login steps and verify the selected account or workspace. Ask Builder to assess the app before choosing a deployment approach.

## Check whether the app can be published

In Tweak, ask Builder to check the app for public website publishing. It inspects the runtime, storage, service credentials, and host dependencies, then reports whether the app is ready, needs specific changes, or is blocked.

Current limitation: the supported publishing workflows do not carry active Runtime Agents, Direct AI helpers, Coding Agent access, or required local host capabilities into the cloud. A configured credential alone does not make a platform-dependent app portable.

A static app must work from its frontend files. A backend app must work as a standalone service with an explicit storage and credential plan.

## Review and publish

1. Review any proposed app adaptations.

2. Check the hosting target, public content, storage, credential use, and expected costs.

3. Approve the concrete publishing plan when it matches your intent.

4. Wait for deployment and verification of the public result.

Local app data and cloud data are separate. Do not assume existing local records will be uploaded, or that cloud records will appear locally.

## Update a published app

Ask Builder to update the existing deployment. It should inspect the recorded target, check the current app and connection, and present the update plan. Check how the update affects persistent data before approving it.

Verify the public URL and a representative user action after deployment. A successful upload is only one part of confirming that a website works.

## Take a website offline

Ask to take the published app offline and specify whether cloud data should be kept. Closing public access, stopping the service, and deleting cloud resources can have different effects on data and billing.

Review the exact target and retention plan before approving the action. Stopping the local AppJuice app does not take down a separate cloud deployment.