Deploy Gitea on your own VPS

Why host Gitea with Better-PaaS

Better-PaaS is designed for apps like Gitea: small services that need reliable routing, a domain, persistent data, and quick redeploys without manually editing reverse proxy files.

Deployment checklist

Before going live, decide the domain, persistent volume, backup cadence, and any environment variables Gitea needs. For Gitea, pay special attention to repositories, issues, pull requests, and packages.

• Choose the app catalog template or Docker image
• Add required environment variables
• Attach a persistent volume if data must survive redeploys
• Deploy and inspect logs
• Add a custom domain after the app is healthy

Operations after launch

Watch logs during the first deploy, confirm storage survives a redeploy, and include the app data in server backups. If the service exposes an admin area, use a strong password and restrict access where appropriate.

How this connects to the Better-PaaS workflow

This page is part of a broader deployment workflow: install the control plane, connect a Git repository or choose a catalog image, configure environment variables, deploy the container, inspect logs, attach a custom domain, and add backups for stateful data. That sequence matters because most hosting decisions are not isolated. A platform choice affects how you debug failed builds, rotate secrets, recover from bad deploys, and keep apps running after the first launch.

Practical next step

If you are using this page to make a decision, turn it into a small test. Deploy one non-critical app, add a temporary domain, force one redeploy, read the logs, and confirm you understand where data is stored. A short trial reveals more than a feature checklist because it tests the full path from source or image to a live HTTPS endpoint.

Better-PaaS catalog settings

For the one-click catalog flow, Better-PaaS treats this as a prebuilt image deployment. The catalog configuration uses image gitea/gitea:1, listens on container port 3000. These details matter because the platform can only switch traffic safely after the container starts and responds as expected.

• Docker image: gitea/gitea:1
• Container port: 3000
• Health check: TCP or default app response
• Persistent paths: /data
• Important env vars: USER_UID, USER_GID
• Required add-ons: none for the basic starter

Production notes

Git hosting benefits from persistent storage and a clear backup/restore plan before teams depend on it.

Pre-launch checklist

A deploy page should answer what a developer does before exposing the app publicly. For deploy Gitea on VPS, the basics are: confirm the app listens on the expected port, keep secrets in environment variables, attach persistent storage for stateful data, test a redeploy, and add a domain only after the app is healthy.

• Confirm build or image startup succeeds.
• Inspect live logs for startup warnings.
• Set required environment variables before first production deploy.
• Attach Postgres, Redis, MySQL, or volumes when the app stores data.
• Verify HTTPS after DNS points at the server.

What makes this different from manual Docker

Manual Docker can run the same app, but you still need to manage routing, TLS certificates, release history, log access, and rollback behavior. Better-PaaS wraps those repeat tasks into the deployment workflow so the app can be maintained from a dashboard while still running as a normal Docker container on your VPS.

Common failure modes

Most deployment failures come from one of four places: the app does not listen on the expected port, a required env var is missing, persistent storage was not mounted, or the custom domain points somewhere else. Better-PaaS helps narrow this down through logs, health checks, and deployment history.

• Port mismatch or hard-coded localhost binding.
• Missing secret, database URL, or public URL.
• State lost because a required volume was not mounted.
• DNS has not propagated to the Better-PaaS server.