browser-agent-server 1.0.2__tar.gz → 1.0.4__tar.gz

browser_agent_server-1.0.4/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,33 @@
+name: Bug report
+description: Something in browser-agent-server or the browser-agent CLI misbehaves
+title: "[bug]: "
+labels: [bug]
+body:
+  - type: input
+    id: version
+    attributes:
+      label: Daemon version
+      description: Output of `browser-agent --version`
+      placeholder: browser-agent 1.0.2
+    validations:
+      required: true
+  - type: input
+    id: environment
+    attributes:
+      label: OS / how it runs
+      placeholder: Ubuntu 24.04, systemd unit, installed via `uv tool install`
+    validations:
+      required: true
+  - type: textarea
+    id: what
+    attributes:
+      label: What happened vs what you expected
+      description: Include the exact command or HTTP request, and steps to reproduce if you have them
+    validations:
+      required: true
+  - type: textarea
+    id: logs
+    attributes:
+      label: Logs
+      description: "`journalctl -u browser-agent -n 50 --no-pager` or the terminal output"
+      render: shell

browser_agent_server-1.0.4/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,8 @@
+blank_issues_enabled: true
+contact_links:
+  - name: Companion project — @vernikr/browser-agent-mcp
+    url: https://github.com/vernikr/browser-agent-mcp
+    about: Issue with the MCP bridge or an MCP client, not the daemon itself? File it there.
+  - name: Docs
+    url: https://github.com/vernikr/browser-agent/tree/main/docs
+    about: Installation, systemd, API and troubleshooting guides

browser_agent_server-1.0.4/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,15 @@
+name: Feature request
+description: Suggest an idea for the daemon, CLI, or API
+title: "[feat]: "
+labels: [enhancement]
+body:
+  - type: textarea
+    id: problem
+    attributes:
+      label: What problem does this solve for you?
+    validations:
+      required: true
+  - type: textarea
+    id: solution
+    attributes:
+      label: Proposed solution / API sketch

{browser_agent_server-1.0.2 → browser_agent_server-1.0.4}/.github/workflows/ci.yml

@@ -4,6 +4,9 @@ on:
   push:
     branches: [main]
   pull_request:
+  schedule:
+    - cron: "17 5 * * 1"   # Mondays 05:17 UTC — catch bit-rotting deps early
+  workflow_dispatch:
 
 jobs:
   python:

browser_agent_server-1.0.4/.github/workflows/deploy-ssh.yml

@@ -0,0 +1,47 @@
+name: deploy-ssh (reusable)
+
+# Push-style continuous deployment to self-hosted servers.
+# Caller passes the app name; the server-side dispatcher /usr/local/bin/deploy-tools
+# resolves it via /etc/deploy-tools.d/<app>.conf (install exact version → restart →
+# healthcheck → auto-rollback). See docs/multi-project-cd.md.
+#
+# Caller:
+#   deploy:
+#     needs: pypi            # or your publish job — deploy only what is published
+#     uses: vernikr/browser-agent/.github/workflows/deploy-ssh.yml@main
+#     with: { app: my-app, tag: ${{ github.ref_name }} }
+#     secrets: inherit       # DEPLOY_SSH_KEY / DEPLOY_HOST / DEPLOY_USER
+
+on:
+  workflow_call:
+    inputs:
+      app:
+        required: true
+        type: string
+        description: App name — must match /etc/deploy-tools.d/<app>.conf on the host
+      tag:
+        required: true
+        type: string
+        description: Git tag that triggered the release, e.g. v1.2.3
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    environment:
+      name: prod
+    steps:
+      # Plain ssh (no third-party action): this key is trusted to drive the prod host.
+      # Server side it is pinned to the dispatcher via authorized_keys forced command:
+      #   command="/usr/local/bin/deploy-tools",no-pty,no-port-forwarding,no-agent-forwarding,no-X11-forwarding
+      - name: Deploy exact version to production
+        env:
+          DEPLOY_SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }}
+          DEPLOY_HOST: ${{ secrets.DEPLOY_HOST }}
+          DEPLOY_USER: ${{ secrets.DEPLOY_USER }}
+        run: |
+          mkdir -p ~/.ssh && chmod 700 ~/.ssh
+          printf '%s\n' "$DEPLOY_SSH_KEY" > ~/.ssh/ci_deploy_key
+          chmod 600 ~/.ssh/ci_deploy_key
+          ssh-keyscan -H "$DEPLOY_HOST" >> ~/.ssh/known_hosts 2>/dev/null
+          VER="${{ inputs.tag }}"; VER="${VER#v}"
+          ssh -i ~/.ssh/ci_deploy_key "$DEPLOY_USER@$DEPLOY_HOST" "deploy ${{ inputs.app }} $VER"

{browser_agent_server-1.0.2 → browser_agent_server-1.0.4}/.github/workflows/release.yml

@@ -49,6 +49,15 @@ jobs:
       - uses: pypa/gh-action-pypi-publish@release/v1
         if: steps.exists.outputs.exists == 'false'
 
+
+  deploy:
+    needs: pypi
+    uses: ./.github/workflows/deploy-ssh.yml
+    with:
+      app: browser-agent
+      tag: ${{ github.ref_name }}
+    secrets: inherit
+
   github-release:
     needs: build
     runs-on: ubuntu-latest

{browser_agent_server-1.0.2 → browser_agent_server-1.0.4}/CHANGELOG.md

@@ -5,6 +5,33 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [1.0.4] - 2026-10-10
+
+### Changed
+
+- CD generalized for multi-project use: the deploy job now calls the reusable
+  workflow `.github/workflows/deploy-ssh.yml`, and the server-side forced
+  command became a dispatcher (`deploy <app> <semver>`) driven by
+  `/etc/deploy-tools.d/*.conf` — playbook in docs/multi-project-cd.md.
+
+### Added
+
+- docs/multi-project-cd.md — how to wire any project on the same server for
+  push-style CD in ~20 minutes (checklist + agent prompt).
+
+
+## [1.0.3] - 2026-10-10
+
+### Added
+
+- Continuous deployment: after a successful PyPI publish, `release.yml` deploys
+  the exact version to the production host over SSH. The CI key is pinned to a
+  single forced command (`deploy-browser-agent` on the server): it installs the
+  exact pinned version from PyPI via `uv tool`, restarts the unit and
+  health-checks `/status`, rolling back to the previous version on failure
+  (see docs/publishing.md → Continuous deployment).
+
+
 ## [1.0.2] - 2026-10-10
 
 ### Added

{browser_agent_server-1.0.2 → browser_agent_server-1.0.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: browser-agent-server
-Version: 1.0.2
+Version: 1.0.4
 Summary: Real headful Chrome on Xvfb with a hardware-level X11 mouse, Cloudflare Turnstile auto-solve and zero-leak CDP. Localhost HTTP API + CLI + Python SDK.
 Project-URL: Homepage, https://github.com/vernikr/browser-agent
 Project-URL: Repository, https://github.com/vernikr/browser-agent
@@ -23,6 +23,12 @@ Description-Content-Type: text/markdown
 
 # browser-agent
 
+[![PyPI](https://img.shields.io/pypi/v/browser-agent-server)](https://pypi.org/project/browser-agent-server/)
+[![CI](https://github.com/vernikr/browser-agent/actions/workflows/ci.yml/badge.svg)](https://github.com/vernikr/browser-agent/actions/workflows/ci.yml)
+[![Release](https://img.shields.io/github/v/release/vernikr/browser-agent)](https://github.com/vernikr/browser-agent/releases)
+[![Python 3.12+](https://img.shields.io/badge/python-3.12%2B-blue)](https://pypi.org/project/browser-agent-server/)
+[![License: MIT](https://img.shields.io/badge/license-MIT-blue)](LICENSE)
+
 > 🔗 **Companion project:** [`@vernikr/browser-agent-mcp`](https://github.com/vernikr/browser-agent-mcp) — the MCP server that exposes this daemon to LLM agents (Claude Code, Cursor, Freebuff…). The two projects are developed together and speak the HTTP contract in [`docs/api.md`](docs/api.md).
 
 **Real headful Chrome on Xvfb with a hardware-level X11 mouse.** One localhost daemon gives any project, script, or AI agent on a Linux box a genuine desktop browser: steered over real XTEST input events on randomized Bézier paths, with zero-leak CDP (no `Runtime.enable`), Cloudflare Turnstile auto-solve, and RAM discipline for tiny VPSes (auto-hibernates to ~12 MB idle).

{browser_agent_server-1.0.2 → browser_agent_server-1.0.4}/README.md

@@ -1,5 +1,11 @@
 # browser-agent
 
+[![PyPI](https://img.shields.io/pypi/v/browser-agent-server)](https://pypi.org/project/browser-agent-server/)
+[![CI](https://github.com/vernikr/browser-agent/actions/workflows/ci.yml/badge.svg)](https://github.com/vernikr/browser-agent/actions/workflows/ci.yml)
+[![Release](https://img.shields.io/github/v/release/vernikr/browser-agent)](https://github.com/vernikr/browser-agent/releases)
+[![Python 3.12+](https://img.shields.io/badge/python-3.12%2B-blue)](https://pypi.org/project/browser-agent-server/)
+[![License: MIT](https://img.shields.io/badge/license-MIT-blue)](LICENSE)
+
 > 🔗 **Companion project:** [`@vernikr/browser-agent-mcp`](https://github.com/vernikr/browser-agent-mcp) — the MCP server that exposes this daemon to LLM agents (Claude Code, Cursor, Freebuff…). The two projects are developed together and speak the HTTP contract in [`docs/api.md`](docs/api.md).
 
 **Real headful Chrome on Xvfb with a hardware-level X11 mouse.** One localhost daemon gives any project, script, or AI agent on a Linux box a genuine desktop browser: steered over real XTEST input events on randomized Bézier paths, with zero-leak CDP (no `Runtime.enable`), Cloudflare Turnstile auto-solve, and RAM discipline for tiny VPSes (auto-hibernates to ~12 MB idle).

browser_agent_server-1.0.4/docs/multi-project-cd.md

@@ -0,0 +1,99 @@
+# Multi-project CD: push every release to production from CI
+
+The deploy used for `browser-agent` generalizes to any number of projects on the same
+server. This page is the one-stop playbook — give it (or the prompt at the bottom) to any
+agent to wire up a new project in ~20 minutes.
+
+## Architecture (once per server)
+
+```
+GitHub release.yml (tag push)
+  build → publish (OIDC, no tokens)
+  → deploy job → reusable workflow deploy-ssh.yml
+       └─ ssh <ci-key>@host "deploy <app> <ver>"
+            └─ authorized_keys forced command → /usr/local/bin/deploy-tools
+                 └─ /etc/deploy-tools.d/<app>.conf
+                      └─ install exact version → restart unit → healthcheck → rollback
+```
+
+- **One CI key serves all projects.** The key is pinned by a forced command to the
+  dispatcher; it cannot open a shell, forward ports, or run anything else.
+- **The whitelist of deployable apps is the server itself**: an app exists iff a
+  root-owned `/etc/deploy-tools.d/<app>.conf` exists. Unknown names are rejected.
+- **No public endpoint, no firewall changes** — push arrives over the SSH port that is
+  already open for admin access.
+
+Server-side artifacts (already installed on 38.244.152.2; copy to a new host as-is):
+
+- `/usr/local/bin/deploy-tools` — the generic dispatcher (protocol: `deploy <app> <semver>`;
+  legacy `deploy <semver>` works while exactly one app is configured).
+- `/etc/deploy-tools.d/browser-agent.conf` — the reference app config.
+- backups under `/root/bak/`.
+
+## Per-project checklist (~20 min)
+
+Prerequisites: the project is a package published from CI to a registry with OIDC
+trusted publishing (same one-time registry setup as in `docs/publishing.md`), and it runs
+on the server as a systemd unit with some health signal.
+
+1. **Systemd unit** — the service must come up healthy after `systemctl restart`. Health
+   signal: either a JSON endpoint answering `"version": "X.Y.Z"` or a CLI
+   `myapp --version`. No JSON endpoint? Put `HEALTH_CMD=...` in the config.
+2. **Server config** — create `/etc/deploy-tools.d/<app>.conf` (app name: `[a-z0-9-]+`):
+
+   ```bash
+   INSTALLER=uv                 # uv (Python) | npm-global (Node)
+   PKG=<registry package name>  # e.g. my-tool-server / @scope/my-tool
+   BIN=<executable name>        # for uv tools (for --version); optional otherwise
+   UNIT=<systemd unit name>
+   STATUS_URL=http://127.0.0.1:PORT/status   # OR: HEALTH_CMD='...'
+   HEALTH_FIELD=version
+   ```
+
+   Test on the host:
+
+   ```bash
+   SSH_ORIGINAL_COMMAND="deploy <app> <current-version>" /usr/local/bin/deploy-tools
+   # expect: "already on <ver> and healthy — nothing to do"
+   ```
+
+3. **Registry/CI side already solved**: publish from `release.yml` exactly like this repo
+   (`pypi`/`npm` job first, so deploy only installs what already exists in the registry).
+4. **Deploy job** in the project's `release.yml`:
+
+   ```yaml
+   deploy:
+     needs: <publish-job>
+     uses: vernikr/browser-agent/.github/workflows/deploy-ssh.yml@main
+     with:
+       app: <app>
+       tag: ${{ github.ref_name }}
+     secrets: inherit
+   ```
+
+5. **Repo secrets** (Settings → Secrets and variables → Actions): `DEPLOY_SSH_KEY`,
+   `DEPLOY_HOST`, `DEPLOY_USER` — the same values as in this repo (reusing the same
+   single-purpose key across repos is fine and simplifies rotation; rotate by replacing
+   the one `authorized_keys` line + the secret values).
+6. **Smoke-release**: tag `vX.Y.Z+1`, watch the Actions tab — deploy should be green and
+   the unit should report the new version on its health endpoint.
+
+Failure semantics: unreadable registry → retries; bad health → automatic reinstall of the
+previous version, restart, re-check, and the CI job turns red. Everything is logged in the
+GitHub job — no `journalctl` digging needed for routine failures.
+
+## Agent prompt (copy-paste to configure a new project)
+
+> Wire the `<PROJECT>` repo for push-style CD to our production server, following
+> `vernikr/browser-agent/docs/multi-project-cd.md`: (1) on the server create
+> `/etc/deploy-tools.d/<app>.conf` for unit `<UNIT>`, package `<PKG>` (`INSTALLER=uv|npm-global`),
+> health via `STATUS_URL=<...>` or `HEALTH_CMD`, then smoke-test with
+> `SSH_ORIGINAL_COMMAND="deploy <app> <current-version>" /usr/local/bin/deploy-tools`;
+> (2) add a `deploy` job to `<PROJECT>`'s `release.yml` that `needs:` the publish job and
+> calls `vernikr/browser-agent/.github/workflows/deploy-ssh.yml@main` with
+> `with: { app: <app>, tag: github.ref_name }` and `secrets: inherit`;
+> (3) add the repo secrets `DEPLOY_SSH_KEY` / `DEPLOY_HOST` / `DEPLOY_USER` (same values as
+> in `vernikr/browser-agent`); (4) ship a patch release and confirm the deploy job is green
+> and the unit reports the new version. Do not touch other services, firewall, or VPN units
+> on the server; before modifying `authorized_keys` or the dispatcher, back the file up to
+> `/root/bak/`.

{browser_agent_server-1.0.2 → browser_agent_server-1.0.4}/docs/publishing.md

@@ -30,3 +30,23 @@ Then still tag, so the GitHub Release and CHANGELOG stay in sync: `git tag vX.Y.
 - Verify: https://pypi.org/pypi/browser-agent-server/json (`info.version`)
 - Bump CHANGELOG under `[Unreleased]` for the next cycle.
 - Revoke the manual token once trusted publishing is proven (pypi.org → Account settings → API tokens).
+
+## Continuous deployment (release → production)
+
+After the PyPI job succeeds, `release.yml` also runs a `deploy` job that ships the exact
+tag version to the production host — no human SSH needed. Design:
+
+- The repo holds three secrets: `DEPLOY_SSH_KEY` (dedicated ed25519 keypair), `DEPLOY_HOST`,
+  `DEPLOY_USER`. The key is **not** the admin key; on the server it is pinned in
+  `authorized_keys` to a single forced command:
+  `command="/usr/local/bin/deploy-browser-agent",no-pty,no-port-forwarding,no-agent-forwarding,no-X11-forwarding`.
+  Even if the GitHub secret leaks, it can only redeploy this one daemon.
+- The server-side script accepts only `deploy <semver>` (anything else is rejected), installs
+  `browser-agent-server==<ver>` from PyPI (`uv tool install --force --refresh`, with retries
+  for registry propagation), restarts the systemd unit and waits for `/status` to report the
+  target version. On healthcheck failure it reinstalls the previous version and restarts again.
+- Idempotent: redeploying the version already running is a no-op success.
+
+Scaling to more projects on the same server: the forced command now points at a generic
+dispatcher — the full playbook (per-project checklist + an agent prompt) is
+[docs/multi-project-cd.md](multi-project-cd.md).

{browser_agent_server-1.0.2 → browser_agent_server-1.0.4}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "browser-agent-server"
-version = "1.0.2"
+version = "1.0.4"
 description = "Real headful Chrome on Xvfb with a hardware-level X11 mouse, Cloudflare Turnstile auto-solve and zero-leak CDP. Localhost HTTP API + CLI + Python SDK."
 readme = "README.md"
 requires-python = ">=3.12"

{browser_agent_server-1.0.2 → browser_agent_server-1.0.4}/uv.lock

@@ -13,7 +13,7 @@ wheels = [
 
 [[package]]
 name = "browser-agent-server"
-version = "1.0.2"
+version = "1.0.4"
 source = { editable = "." }
 dependencies = [
     { name = "trafilatura" },