
Company News
Socket Named to Rising in Cyber 2026 List of Top Cybersecurity Startups
Socket was named to the Rising in Cyber 2026 list, recognizing 30 private cybersecurity startups selected by CISOs and security executives.
@opencode-cloud/core
Advanced tools
[!WARNING] This tool is still a work in progress and is rapidly evolving. Expect frequent updates and breaking changes. Follow updates at https://github.com/pRizz/opencode-cloud (mirror: https://gitea.com/pRizz/opencode-cloud). Stability will be announced at some point. Use with caution.
A production-ready toolkit for deploying and managing opencode as a persistent cloud service, sandboxed inside a Docker container for isolation and security.
This project uses the opencode fork at https://github.com/pRizz/opencode, which adds additional authentication and security features.
cargo install opencode-cloud
opencode-cloud --version
npx opencode-cloud@latest --version
bunx opencode-cloud@latest --version
Or install globally:
npm install -g opencode-cloud
opencode-cloud --version
Quick deploy provisions a private EC2 instance behind a public ALB with HTTPS. A domain name is required for ACM certificate validation. A Route53 hosted zone ID is required for automated DNS validation.
Docs: docs/deploy/aws.md (includes teardown steps and S3 hosting setup for forks)
Credentials: docs/deploy/aws.md#retrieving-credentials
Marketplace one-click deploy provisions a Droplet that bootstraps opencode-cloud on first boot (listing pending).
Manual Droplet setup: docs/deploy/digitalocean-droplet.md
Marketplace docs: docs/deploy/digitalocean-marketplace.md
opencode-cloud / occ) - Works on Linux and macOSopencode-cloud runs opencode inside a Docker container, providing:
The CLI manages the container lifecycle, so you don't need to interact with Docker directly.
The sandbox container image is named opencode-cloud-sandbox (not opencode-cloud) to clearly distinguish it from the CLI tool. The preferred way to use and manage the image is via the opencode-cloud CLI (GitHub, mirror: https://gitea.com/pRizz/opencode-cloud). It handles image pulling, container setup, and upgrades for you.
Why use the CLI? It configures volumes, ports, and upgrades safely, so you don’t have to manage docker run flags or image updates yourself.
The image is published to both registries (Docker Hub is the primary distribution):
| Registry | Image |
|---|---|
| Docker Hub | prizz/opencode-cloud-sandbox |
| GitHub Container Registry | ghcr.io/prizz/opencode-cloud-sandbox |
Pull commands:
Docker Hub:
docker pull prizz/opencode-cloud-sandbox:latest
GitHub Container Registry:
docker pull ghcr.io/prizz/opencode-cloud-sandbox:latest
For most users: Just use the CLI - it handles image pulling/building automatically:
occ start # Pulls or builds the image as needed
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shcargo install opencode-cloud
occ --version
npx opencode-cloud@latest --version
bunx opencode-cloud@latest --version
Or install globally:
npm install -g opencode-cloud
occ --version
# Install as a system service (recommended for background use)
occ install
# Start the service
occ start
# GitHub (primary)
git clone https://github.com/pRizz/opencode-cloud.git
# Gitea (mirror)
git clone https://gitea.com/pRizz/opencode-cloud.git
cd opencode-cloud
cargo install --path packages/cli-rust
# GitHub (primary)
git clone https://github.com/pRizz/opencode-cloud.git
# Gitea (mirror)
git clone https://gitea.com/pRizz/opencode-cloud.git
cd opencode-cloud
just build
cargo run -p opencode-cloud -- --version
# Show version
occ --version
# Start the service (builds Docker container on first run, ~10-15 min)
occ start
# Start on a custom port
occ start --port 8080
# Start and open browser
occ start --open
# Check service status (includes broker health: Healthy/Degraded/Unhealthy)
occ status
# View logs
occ logs
# Follow logs in real-time
occ logs -f
# View opencode-broker logs (systemd/journald required)
occ logs --broker
# Troubleshoot broker health issues reported by `occ status`
occ logs --broker --no-follow
# Note: Broker logs require systemd/journald. This is enabled by default on supported Linux
# hosts. Docker Desktop/macOS/Windows use Tini, so broker logs aren't available there.
# Existing containers may need to be recreated after upgrading.
# Stop the service
occ stop
# Restart the service
occ restart
# Check for updates and choose what to update
occ update
# Update the opencode-cloud CLI binary
occ update cli
# Update the opencode-cloud container image
occ update container
# Update opencode inside the container
occ update opencode
# Update opencode using a specific branch or commit
occ update opencode --branch dev
occ update opencode --commit <sha>
# Remove the container (keeps volumes)
occ reset container
# Remove container and volumes (data loss)
occ reset container --volumes --force
# Clean bind mount contents (data loss)
occ mount clean --force
# Purge bind mounts (data loss, removes config entries)
occ mount clean --purge --force
# Factory reset host (container, volumes, mounts, config/data)
occ reset host --force
### Container Mode
When `occ` runs inside the opencode container, it will auto-detect this and switch to **container runtime**.
Override if needed:
```bash
occ --runtime host <command>
OPENCODE_RUNTIME=host occ <command>
Supported commands in container runtime:
occ statusocc logsocc userocc update opencodeNotes:
occ logs and occ update opencode require systemd inside the container. If systemd is not available, run those commands from the host instead.When running in foreground mode (for example via occ install, which uses occ start --no-daemon),
the host listens for a command file on a bind mount. The webapp can write a simple JSON payload
to request an update.
Default paths (with default bind mounts enabled):
~/.local/state/opencode/opencode-cloud/commands/update-command.json/home/opencode/.local/state/opencode/opencode-cloud/commands/update-command.jsonExample payload:
{
"command": "update_opencode",
"request_id": "webapp-1234",
"branch": "dev"
}
The host writes the result to:
~/.local/state/opencode/opencode-cloud/commands/update-command.result.json
occ install
occ uninstall
occ config show
## Authentication
opencode-cloud uses **PAM (Pluggable Authentication Modules)** for authentication. Users created via `occ user add` authenticate to the opencode web UI.
### Creating Users
Create a user with a password:
```bash
occ user add <username>
Generate a random password:
occ user add <username> --generate
occ user listocc user passwd <username>occ user remove <username>occ user enable <username> / occ user disable <username>User accounts (including password hashes and lock status) persist across container updates and rebuilds.
The CLI stores user records in a managed Docker volume mounted at /var/lib/opencode-users inside the container.
No plaintext passwords are stored on the host.
The auth_username and auth_password config fields are deprecated and ignored. They are kept in the config schema for backward compatibility with existing deployments, but new users should be created via occ user add instead.
To migrate from legacy fields:
occ user add <username>When developing locally or after updating opencode-cloud, you may need to rebuild the Docker image to pick up changes in the embedded Dockerfile:
# Rebuild using Docker cache (fast - only rebuilds changed layers)
occ start --cached-rebuild
# Rebuild from scratch without cache (slow - for troubleshooting)
occ start --full-rebuild
--cached-rebuild (recommended for most cases):
--full-rebuild (for troubleshooting):
When to rebuild:
--cached-rebuild--cached-rebuild--cached-rebuild first, then --full-rebuild--full-rebuildConfiguration is stored at:
~/.config/opencode-cloud/config.jsonData (PID files, etc.) is stored at:
~/.local/share/opencode-cloud/# Install dependencies
pnpm install
# Configure git hooks (once after cloning)
git config core.hooksPath .githooks
# Build everything
just build
# Compile and run occ (arguments automatically get passed to the binary)
just run --version
# Run tests
just test
# Format and lint
just fmt
just lint
Note: The git hooks automatically sync
README.mdto npm package directories on commit.
This is a monorepo with:
packages/core - Rust core librarypackages/cli-rust - Rust CLI binary (recommended)packages/cli-node - Node.js CLI (fully supported and in parity with the Rust CLI)The packages/core/Cargo.toml file must use explicit values rather than workspace = true references.
When updating package metadata (version, edition, rust-version, etc.), keep both files in sync:
Cargo.toml (workspace root)packages/core/Cargo.tomlUse scripts/set-all-versions.sh <version> to update versions across all files automatically.
MIT
FAQs
Core NAPI bindings for opencode-cloud (internal package)
We found that @opencode-cloud/core demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Company News
Socket was named to the Rising in Cyber 2026 list, recognizing 30 private cybersecurity startups selected by CISOs and security executives.

Research
Socket detected 84 compromised TanStack npm package artifacts modified with suspected CI credential-stealing malware.

Security News
A dispute over fsnotify maintainer access set off supply chain alarms around one of Go’s most widely used filesystem libraries.