Self-hosted OpenVPN VPS setup with an AI agent

Set up a private self-hosted OpenVPN server on a VPS with an agent-led workflow, Hetzner tested path, secure local outputs, and clear guardrails.

Harllens George | 2026-05-26

one-click-self-hosted-openvpn is a practical self-hosted OpenVPN VPS project for people who want a small private VPN they control. The repository gives an AI agent a careful setup contract instead of asking the operator to copy random shell commands from a blog post.

The first tested path is a Hetzner Cloud VPS in Germany running OpenVPN Community Edition. The project is structured so more providers, operating systems, and setup modules can be added over time.

What this is

This is an agent-ready OpenVPN setup repository. It documents the inputs, safety checks, provider assumptions, local output paths, and guarded helper commands needed to configure a private VPN server on a VPS.

It is not a commercial VPN service, and it is not OpenVPN Access Server. The project uses OpenVPN Community Edition with SSH administration, no public admin UI, and local-only storage for generated private files.

Who it is for

Developers who want a private VPS-based VPN under their own control
Operators who prefer explicit firewall and SSH hardening over black-box VPN apps
Builders who want an AI agent to help, but only through a documented and reviewable process

Get it

Repository: Just-Boring-Cat/one-click-self-hosted-openvpn

Current compatibility

First tested provider: Hetzner Cloud
First tested region: Germany
First tested operating system: Ubuntu 24.04 LTS
VPN stack: OpenVPN Community Edition
Admin model: SSH only, with no public OpenVPN admin UI

Other providers and operating systems are extension targets. The agent is expected to stop if the provider or OS path is unknown.

Why this matters

Commercial VPNs are easy to buy, but shared exit IPs can be noisy, blocked, or flagged. A private VPS-hosted VPN gives you a dedicated server, direct control over client profiles, and a configuration you can inspect.

The tradeoff is responsibility. You own the server, the firewall, the client profiles, the SSH keys, the certificate authority, and the update path. This project is useful because it makes that responsibility explicit instead of hiding it behind a one-line installer.

What the repository gives you

The current project includes:

an .env.example input contract for the operator and agent
a guarded scripts/setup-openvpn.sh helper
Hetzner provider documentation
an OS support matrix
OpenVPN operations and verification notes
security guidance for private keys, .ovpn profiles, logs, and server notes
ignored local/ folders for private runtime outputs

The helper script is intentionally not the whole product. It supports collection, validation, inspection, and planning. The actual setup still requires review and operator confirmation at security-sensitive points.

Agent-led setup flow

A safe agent-led flow looks like this:

Read the playbook and setup docs.
Collect the required values into .env.
Verify SSH access before hardening anything.
Inspect the server and operating system.
Confirm provider firewall expectations.
Print the setup plan.
Execute only the provider and OS path that has been reviewed.
Store generated client profiles under ignored local paths.

The public README gives this instruction to an agent:

Use this repository to configure my private OpenVPN server. Read docs/agent-playbook.md and docs/agent-setup.md first. Help me fill .env from .env.example, inspect the server over SSH, choose the correct provider and OS path, run the setup helpers when needed, and place generated client profiles only under local/clients/.

Setup helper commands

The helper supports the early setup flow:

cp .env.example .env
scripts/setup-openvpn.sh --requirements
scripts/setup-openvpn.sh --collect
scripts/setup-openvpn.sh --check
scripts/setup-openvpn.sh --inspect
scripts/setup-openvpn.sh --plan

These commands are useful because they slow the process down at the right moments. The agent should inspect the system, explain the plan, and stop if an unsupported OS, missing firewall rule, failed SSH check, or secret-handling risk appears.

Security model

The security model is deliberately small:

no public OpenVPN admin UI
no provider tokens committed to Git
no generated .ovpn profiles committed to Git
no SSH private keys committed to Git
no real server IPs in public docs
SSH access verified before hardening
OS inspected before package installation
private runtime files stored under ignored local/ paths

This does not guarantee anonymity, legal compliance, uptime, or protection from a compromised VPS provider or client device. It is a practical setup pattern for a private VPN, not a promise of perfect privacy.

Common mistakes to avoid

Running setup commands before the server OS is inspected
Disabling root SSH before non-root sudo access is verified
Publishing generated .ovpn profiles or CA material
Assuming every VPS image behaves like Ubuntu
Opening TCP 443 without actually configuring an OpenVPN TCP fallback
Treating provider firewalls and host firewalls as interchangeable without checking both

When this is a good fit

This project is a good fit when you want a private VPN for personal or small-team use and you are comfortable owning the operational responsibility. It is especially useful if you want the setup to be repeatable, reviewable, and agent-friendly.

It is not a good fit if you need managed support, broad anonymous VPN infrastructure, many users, or a public admin dashboard.

Next steps

Start by reading the repository README and the agent playbook. Then decide whether the tested Hetzner and Ubuntu path matches your needs. If it does, prepare a clean VPS, configure provider firewall rules, fill .env, and run the guarded helper commands in order.

If you want to contribute, provider modules, OS modules, firewall patterns, validation checks, and safer OpenVPN profile variants are all useful areas.

Conclusion

A self-hosted OpenVPN VPS is useful when control matters more than convenience. one-click-self-hosted-openvpn turns that setup into a documented, agent-led workflow with clear stop conditions and private-file boundaries.