[andy-vdg]

✍️ Description

New script: agentgateway — the Linux Foundation's open-source proxy for AI agents (MCP servers, LLM providers, HTTP APIs), Apache-2.0, Rust, single static binary.

• ct/agentgateway.sh, install/agentgateway-install.sh, json/agentgateway.json.
• Install: fetch_and_deploy_gh_release … "singlefile" (latest release), then the binary is checked against the release's own .sha256 asset before anything runs it.
• Config /etc/agentgateway/config.yaml is the config agentgateway bootstraps itself when started without one: a default gateway on port 4000 with the UI on it, state in SQLite (here /opt/agentgateway_data/data.db, outside the deploy target). The easy way in is http://<IP>:4000/ui, where agentgateway's Welcome to Agentgateway wizard guides the first setup. The admin interface stays on 127.0.0.1:15000, upstream's default (it has no authentication and serves shutdown/config-dump endpoints).
• No authentication is added by the script, as upstream ships it; the json notes say so and link upstream's guide for ui.policies (basicAuth, OIDC, JWT).
• Update: check_for_gh_release, redeploy, checksum check again. No backup needed: config (/etc/agentgateway) and data (/opt/agentgateway_data) live outside the deploy target.

Upstream research: agentgateway ships prebuilt agentgateway-linux-amd64 / -arm64 binaries with .sha256 files on every GitHub release; no external runtime or database server (SQLite is built in). The config is exactly what agentgateway writes to ~/.config/agentgateway/config.yaml on a first run without -f (checked on v1.6.0: config.database.url sqlite, gateways.default.port: 4000, ui.gateways: default), with the database moved to /opt/agentgateway_data. Without that database the Welcome wizard does not appear. No Dockerfile is needed for a bare-metal install of a static binary.

🔗 Related PR / Issue

Link: none

✅ Prerequisites

• Self-review completed – Code follows project standards.
• Tested thoroughly – Changes work as expected.
• No breaking changes – Existing functionality remains intact.
• No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.

🏗️ arm64 Support

• arm64 supported - Tested and supported on arm64.
• arm64 not tested - Assumed to work on arm64, but testing has not been done. (No arm64 Proxmox host available, so the container create itself is untested on arm64. The application part was tested natively on arm64 (Apple Silicon, Debian 13 trixie arm64 container): agentgateway-linux-arm64 v1.6.0 checksum matched the release .sha256, the script's config validated, the UI answered 200 on port 4000 and the SQLite database was created. Upstream publishes the arm64 binary and checksum on every release, so var_arm64=yes.)
• arm64 not supported

🖥️ Tested on

• Proxmox VE – Created on a Proxmox VE host and the app works.
• Incus

Tested on Proxmox VE 9, Debian 13 template, unprivileged: unattended create and an interactive create through the menus; from another LAN host :4000/ui → 200 and the Welcome wizard opens, :15000 not reachable; pct reboot → UI back; update path from a lowered ~/.agentgateway → new release deployed, checksum verified, config and data unchanged, UI 200.

🛠️ Type of Change

• 🆕 New script – A fully functional and tested script or script set.

🔍 Code & Security Review

• Follows CODE-AUDIT.md & CONTRIBUTING.md guidelines
• Uses correct script structure (AppName.sh, AppName-install.sh, AppName.json)
• No hardcoded credentials
• No Docker / Docker Compose
• No git pull

🤖 AI Assistance

• No AI used
• AI was used – built using AGENTS.md and .github/agents/pve-script-creator.agent.md as guidance, output reviewed and corrected to match.

Claude Opus 5.5 (Anthropic), in Claude Code, used to draft both scripts and the JSON from AGENTS.md, run the test builds on my Proxmox host, and fix what the tests found. I reviewed the result and directed the changes.

One addition beyond the template: after fetch_and_deploy_gh_release, both the install and the update verify the binary against the .sha256 file upstream publishes for each release asset, and stop if it does not match. No helper covers this, so it is a few lines of curl + sha256sum. If you would rather keep to the template, I will remove it.

📦 Application Requirements

• The application is at least 6 months old
• The application is actively maintained (latest release 2026-10-21)
• The application has 600+ GitHub stars (5.5k)
• Official release tarballs are published (prebuilt binaries + checksums per release)
• I understand that not all scripts will be accepted due to various reasons and criteria by the community-scripts ORG

🌐 Source

• https://github.com/agentgateway/agentgateway
• https://agentgateway.dev/docs/

[github-actions]

Try this script

ct/agentgateway.sh, run in the Proxmox VE shell or on an Incus host:

COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/andy-vdg/DevScripts/agentgateway \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/andy-vdg/DevScripts/agentgateway/ct/agentgateway.sh)"

COMMUNITY_SCRIPTS_URL is not optional for ct/. Fetching the ct/ script from a
branch does not tell the engine where that branch is — with bash -c "$(curl …)"
there is no file on disk for the scripts root to be derived from, so it would fall
back to upstream main and look for the install script there.

Against a core branch as well

Add COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/OWNER/core/BRANCH
to test an engine change at the same time. The two resolve independently.

Useful flags while testing

dev_mode=net logs every fetch with status and duration, so you can confirm the
branch is really being used. dev_mode=keep stops a failed build from deleting
the container along with the evidence.

[CrazyWolf13]

remove comments and the if check

[CrazyWolf13]

we have a backup and restore function. can you use that like other scripts do?