Benchpress

bench get-app https://github.com/Venkateshvenki404224/benchpress

[![Listed on Frappe Gems](https://frappegems.com/api/method/frappe_gems.seo.badge?app=Venkateshvenki404224%2Fbenchpress)](https://frappegems.com/gems/apps/Venkateshvenki404224/benchpress)

--- ## What is BenchPress? A Frappe bench for a demo, a bug report, or a new hire costs an afternoon of Docker, database and network setup. The work repeats for every environment, on a machine somebody then has to keep tidy. BenchPress turns that afternoon into a form. Describe a **lab** once — a Frappe version and a list of apps. BenchPress builds an image, deploys a container, gives it a private WireGuard address and a public HTTPS address, and hands back an SSH command and a working site. Delete the bench when the task is done. That is the whole loop: define once, deploy in a click, tear down. BenchPress solves a narrower problem than a hosting platform such as Frappe Cloud, and it does not replace one. A lead defines the app stack for a project. A new developer then deploys it and starts work in minutes. BenchPress is itself a Frappe app. It installs into a bench you already run. A Vue 3 single-page app sits on the front. `frappe.qb` queries and background jobs sit on the back. > **Disposable sandboxes, not production hosting.** A lab is a throwaway > development environment, and its screens show credentials in plain text. Read > [Production safety](docs/operator/production-safety.mdx) before you point > anything important at it. --- ## The Problem Setting up a Frappe or ERPNext development environment costs a day, and the day repeats. 1. **Manual setup.** Install the bench CLI, MariaDB, Redis, Node.js, wkhtmltopdf and a dozen more dependencies. 2. **Version conflicts.** Two projects want two Frappe versions, and the host operating system ends up carrying both. 3. **No isolation.** One broken bench reaches everything else on the machine. 4. **No remote access.** A teammate cannot open the environment where the bug reproduces. 5. **Repetition.** Every new project and every new person pays the same setup cost again. Nothing lets a team say *"give me a Frappe bench with ERPNext and HRMS"* and get one in minutes. --- ## The Solution BenchPress automates the bench lifecycle behind a web interface. It is not a Frappe Cloud alternative. It gets a developer or an intern a working bench in minutes rather than a day. 1. **Define a lab.** Pick the Frappe version, the apps and the resource limits, or start from one of the ready-made catalog templates. 2. **Build once.** A layer-cached Docker build produces one image for each lab. Only the layers below a change rebuild. 3. **Deploy in a click.** Each bench is a container with its own SSH server, its own site and a browser VS Code session. 4. **Reach it privately.** Every bench gets a WireGuard address. No bench port is published on the public internet. 5. **Watch it happen.** The eleven deploy steps and the raw build output stream into the browser over socket.io. 6. **Manage it.** Start, stop, restart, redeploy and delete from the dashboard, with CPU and memory sampled for every running bench. --- ## Architecture The browser calls the control plane over HTTPS and socket.io. The control plane puts slow work on a Redis queue. A worker drives the Docker engine. Traefik terminates TLS for the public address of a bench. WireGuard carries the private one. Every bench keeps its site database in one shared MariaDB. ```mermaid flowchart TD Browser["Browser
Vue 3 SPA (frappe-ui)"] Web["Control plane
the BenchPress Frappe app
api.py · hooks.py · vpn_adapter.py"] RQ["Redis queue (RQ)
queue-long carries the Docker socket"] DM["deploy_pipeline.py
docker_manager.py"] Docker["Docker engine"] Traefik["Traefik
wildcard TLS on 80 and 443"] WG["WireGuard wg0
owned by vpn_management"] Bridge["Bench bridge benchpress-N
10.20.x.0/20"] C1["Bench container
site 8000 · code-server 8080"] C2["Bench container"] MariaDB[("benchpress-mariadb
one site database per bench")] Browser -- "HTTPS / socket.io" --> Web Web --> RQ RQ --> DM DM --> Docker Docker --> Bridge Bridge --> C1 Bridge --> C2 Traefik -- "https://<id>.<base domain>" --> C1 WG -- "tunnel address" --> C1 C1 --> MariaDB C2 --> MariaDB ``` ### How the pieces fit together | Component | Role | |---|---| | **Control plane** | The BenchPress app in its own bench. It serves the SPA, answers the whitelisted API, and never runs a bench's code | | **Redis queue** | Carries image builds and deploys. Only `backend` and `queue-long` hold the Docker socket, so a deploy must run on `queue-long` | | **Docker engine** | Builds one image for each lab, then creates and destroys containers under CPU and memory limits | | **Traefik** | Terminates TLS for `.` and `ide-.`, from a flat route directory with one file per bench | | **WireGuard** | The tunnel plane, owned by the [vpn_management](https://github.com/Venkateshvenki404224/vpn_management) app. Each bench and each registered device claims one address | | **Shared MariaDB** | One `benchpress-mariadb` container holds every bench site's database. Backed up nightly | | **Bench container** | A Frappe bench with an SSH server, the lab's apps, its site on port 8000 and code-server on port 8080 | A bench answers on up to four addresses at once. [Networking](docs/reference/networking.mdx) names all four and says who can reach each one. [Architecture](docs/reference/architecture.mdx) lists every module and what it owns. --- ## Features - **Lab templates.** A catalog of ready-made stacks, plus a form for a stack the catalog does not carry. See [Deploy from a template](docs/user/deploy-from-template.mdx). - **Layer-cached image builds.** System packages, SSH, the bench, the apps and the site each cache separately. Only the layers below a change rebuild. - **Golden images.** A lab's finished site is baked into the lab image as a database dump, so a deploy restores it instead of creating the tables again. Measured on a 2-vCPU host, the site step falls from 37.2 s to 9.1 s and the whole deploy from 43.3 s to 13.3 s. See [Golden images](docs/operator/golden-images.mdx). - **Live build and deploy logs.** A collapsible step viewer streams the eleven deploy steps and the raw Docker output over socket.io. - **WireGuard access.** Every bench claims a tunnel address. Nothing about a bench is published on a port of the host. - **Browser VS Code.** Each bench runs code-server on port 8080. Hand a teammate a live session instead of describing the bug. - **VPN devices.** Register a laptop or a phone, download its WireGuard config, and run a connection test when a site does not open. - **Resource limits.** CPU cores and memory for each lab, enforced by Docker. - **Lifecycle actions.** Start, stop, restart, redeploy and delete, each stating what it keeps and what it destroys. - **Stats and health.** CPU, memory and container health sampled for every running bench, with eleven read-only host checks beside them. - **Two roles.** BenchPress Admin and BenchPress User. Ownership, not the role, decides which benches a person sees. - **Optional metering.** Credits, leases, concurrency caps and self-serve signup are all off by default and do not apply to a plain install. --- ## Screenshots Four screens, in the order a new user meets them. Every screen is described in full on its own documentation page. **The Overview dashboard** counts what you own and how long a deploy has been taking. It is the screen a login lands on.  **A deploy in progress** shows the eleven pipeline steps as they complete, each with its own duration.  **A running bench** reports its container status, its health, its resource use and the site the deploy created.  **code-server** puts a VS Code window on the bench in the browser, rooted at the bench directory.  --- ## Documentation The documentation is the source of truth. This page is a map into it. Start at [docs/index.mdx](docs/index.mdx), or pick a track below. An agent working in a clone should read [AGENTS.md](AGENTS.md) instead, which points at the flattened copy in `docs-bundle/`. ### User track — you were handed a login | Page | What it covers | |---|---| | [Quick tour](docs/user/quick-tour.mdx) | The five screens in the sidebar, and every number the Overview dashboard reports | | [Deploy from a template](docs/user/deploy-from-template.mdx) | Turn a catalog template into a running bench, and read the eleven pipeline steps while they run | | [Create a lab](docs/user/create-a-lab.mdx) | Fill in the New lab form when no catalog template matches the app list you need | | [Read a lab page](docs/user/lab-detail.mdx) | Every field on the lab page, and why container status and container health can disagree | | [Start, stop and redeploy](docs/user/lifecycle.mdx) | The