# Ops Tmux Remote Deploy

> Run remote deploy via SSH using tmux sessions (frps + app), with idempotent restart and health checks

- **Type:** Skill
- **Install:** `agentstack add skill-frontier-ai-next-mgarlbot-ops-tmux-remote-deploy`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [frontier-ai-next](https://agentstack.voostack.com/s/frontier-ai-next)
- **Installs:** 0
- **Category:** [Cloud & Infrastructure](https://agentstack.voostack.com/c/cloud-infrastructure)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [frontier-ai-next](https://github.com/frontier-ai-next)
- **Source:** https://github.com/frontier-ai-next/mgarlbot/tree/main/skills/ops_tmux_remote_deploy

## Install

```sh
agentstack add skill-frontier-ai-next-mgarlbot-ops-tmux-remote-deploy
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

## Remote deploy via tmux (single VPS baseline)

Use this skill when the user wants: "deploy on that server", "run frps and project in tmux", "keep processes alive after disconnect".

Always run commands on VPS via SSH wrapper:

```bash
ssh -F /data/.ssh/config vps 'REMOTE_COMMAND_HERE'
```

Never run host-level commands locally when the task is explicitly remote.

### Goal

Create and maintain two tmux sessions on the VPS:

- `frps` — FRP server process.
- `project_app` — project runtime process (docker compose or native command).

Both sessions must be idempotent and verifiable.

### Standard sequence

1. **Preflight**
   - Verify SSH connectivity.
   - Check core tools: `tmux`, `curl`, `ss` (or `netstat` fallback).
   - Install `tmux` if missing (non-interactive apt for Debian/Ubuntu).

2. **Prepare frps**
   - Ensure `frps` binary + config path are known (ask only if impossible to infer).
   - Restart `frps` session safely:
     - `tmux has-session -t frps` -> kill if exists.
     - start detached with explicit command and logs.

3. **Prepare app runtime**
   - If repo has compose files and user asked containerized deploy: use `docker compose up` in `project_app`.
   - Otherwise start provided app command in `project_app`.
   - Same idempotent session restart pattern as `frps`.

4. **Health checks (mandatory)**
   - `tmux ls` contains both sessions.
   - Process check (`pgrep -af frps`, app process or `docker compose ps`).
   - Port check with `ss -ltnp` for expected bind ports.
   - HTTP check with `curl -fsS` (or status code check) for app endpoint.

5. **Operational output**
   - Report only operational facts: session names, process status, listening ports, endpoint status.
   - Provide follow-up commands for logs:
     - `tmux capture-pane -pt frps -S -120`
     - `tmux capture-pane -pt project_app -S -120`

### Canonical command snippets

SSH preflight:

```bash
ssh -F /data/.ssh/config vps 'set -e; uname -a; command -v tmux >/dev/null || echo "__NO_TMUX__"'
```

Install tmux if required:

```bash
ssh -F /data/.ssh/config vps 'set -e; if ! command -v tmux >/dev/null; then DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y tmux; fi'
```

Restart `frps` session:

```bash
ssh -F /data/.ssh/config vps 'set -e; tmux has-session -t frps 2>/dev/null && tmux kill-session -t frps || true; tmux new-session -d -s frps "cd /opt/frp && ./frps -c /opt/frp/frps.toml"'
```

Restart app session (compose variant):

```bash
ssh -F /data/.ssh/config vps 'set -e; tmux has-session -t project_app 2>/dev/null && tmux kill-session -t project_app || true; tmux new-session -d -s project_app "cd /srv/myapp && docker compose up --build"'
```

Health checks:

```bash
ssh -F /data/.ssh/config vps 'set -e; tmux ls; pgrep -af frps || true; ss -ltnp | sed -n "1,120p"; curl -sS -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/'
```

### Rules

- Do not claim success until all mandatory checks pass.
- If checks fail, inspect tmux panes and fix one issue per iteration.
- Do not dump `.env`, private keys, or full secret-bearing configs in chat.
- Avoid destructive global actions; only touch sessions/processes related to this deploy.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [frontier-ai-next](https://github.com/frontier-ai-next)
- **Source:** [frontier-ai-next/mgarlbot](https://github.com/frontier-ai-next/mgarlbot)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** yes
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-frontier-ai-next-mgarlbot-ops-tmux-remote-deploy
- Seller: https://agentstack.voostack.com/s/frontier-ai-next
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.