VPSでGiteaをセルフホストする方法

VoyraCloud VPS上でGiteaを自己ホスティングするには、プリインストールされたアプリケーションイメージを選択し、SSHを通じて最初の管理者を作成し、その後、ウェブインターフェース、HTTPS Git、またはSSH Gitを使用してリポジトリを管理します。このイメージは手動インストールのステップを省略し、アカウントポリシー、ドメイン、HTTPS、リポジトリアクセス、アップデート、バックアップ、インシデントレスポンスはすべてあなたの管理下にあります。

TL;DR

VoyraCloud Giteaアプリケーションイメージは、Cloud VPSおよびResidential IP VPS上にプリインストールされたGitea Community Editionインスタンスを提供します。
インストールページは配信前にロックされています。公開されているインストールウィザードではなく、リソースの詳細に表示されているSSHコマンドを通じて最初の管理者を作成してください。
ポート3000はVPSループバックインターフェースにバインドされています。最初のウェブログインにはリソースの詳細にあるSSHトンネルコマンドを使用してください。これは公開HTTPとしては公開されていません。
ウェブインターフェースを公開する前に、ドメイン、リバースプロキシ、およびブラウザが信頼するHTTPSを追加してください。Gitea SSH Gitは、アカウントに公開鍵を追加した後、別の公開ポート2222を使用します。
新規ユーザー登録はデフォルトで無効になっています。管理者はユーザーを手動で作成するか、登録ポリシーを変更するかを決定します。
リポジトリ、アカウント、問題、プルリクエスト、パッケージ、添付ファイル、設定、シークレットは通常のVPS再起動を通じて持続しますが、再起動の持続性はオフサーバーバックアップではありません。
VoyraCloudは配信後にGiteaインスタンスを自動的にアップグレード、バックアップ、監視、または管理しません。

Giteaとは何ですか？

Giteaは、Gitリポジトリをホスティングし、ソースコードで協力するためのオープンソースソフトウェア開発サービスです。 標準的なGitワークフローに基づいたウェブインターフェースを提供し、ユーザーアカウント、組織、リポジトリの権限、プルリクエスト、問題、プロジェクト、ウィキ、リリース、パッケージ、ウェブフック、およびAPIアクセスを含みます。

公式Giteaドキュメントは、自分のサービスを運営したいチーム向けのインストールと管理について説明しています。自己ホスティングは、リポジトリサービス、ストレージ場所、アカウントポリシー、ネットワークアクセス、アップデートのタイミング、バックアッププロセスを自分の管理下に置きたい場合に便利です。

Gitea VPSは以下のような場合に実用的です：

個人サーバー上でプライベートリポジトリを持ちたい開発者。
Gitホスティング、コードレビュー、問題、組織の権限が必要な小規模チーム。
クライアントプロジェクト用に別々のリポジトリを保持するエージェンシー。
SSHキー、アクセストークン、ウェブフック、またはAPIを通じてリポジトリをデプロイメントシステムに接続するインフラチーム。
より大きなソフトウェア開発プラットフォームの軽量な代替が必要なラボまたは内部環境。

自己ホスティングはリポジトリ操作をメンテナンスフリーにするわけではありません。誰かがオペレーティングシステムのセキュリティ、Giteaのアップデート、認証ポリシー、HTTPS、バックアップ、ストレージの成長、悪用防止、回復テストを所有しています。

VoyraCloud Giteaイメージの使い始め方は？

最も迅速なデプロイメントパスは、Giteaイメージを使用してサポートされているVoyraCloud VPSを作成し、リソースの詳細からプライベート管理者セットアップコマンドを実行することです。 Docker、Gitea、または初期データベースを手動でインストールする必要はありません。

上記のリンクからGiteaのVoyraCloudページを開き、VPS購入フローに進みます。
対象となるCloud VPSまたはResidential IP VPSの構成を選択します。Cloud VPSはGitホスティングの一般的なオプションであり、Residential IP VPSは、広範なワークロードがその製品のネットワーク特性を特に必要とする場合に利用可能です。
選択したVPS製品で現在提供されている任意の地域を選択し、ImagesセクションでGiteaが選択されていることを確認します。
VPSを作成し、リソースとアプリケーションが準備完了になるまで待ちます。
リソースの詳細を開き、アプリケーションセクションを見つけます。
管理者セットアップコマンドをコピーします。これは以下のパターンに従います：

ssh -t -p <ssh-port> <ssh-user>@<server-ip> 'sudo /usr/local/sbin/voyra-gitea-create-admin'

7. ターミナルからコマンドを実行し、管理者のユーザー名とメールアドレスを入力します。Giteaの公式CLIは24文字の一時的なランダムパスワードを生成し、現在のSSHセッションでのみ表示されます。

8. アプリケーションセクションからSSHトンネルコマンドをコピーし、そのターミナルセッションを開いたままにします。これは以下のパターンに従います：

ssh -N -L 3000:127.0.0.1:3000 -p <ssh-port> <ssh-user>@<server-ip>

9. ブラウザでローカルアクセスURLを開きます：

http://127.0.0.1:3000

10. 管理者アカウントと一時パスワードでサインインし、Giteaが変更を要求した際に新しいパスワードを設定します。

11. プライベートテストリポジトリを作成し、SSH公開鍵を追加し、1つのSSHクローンとプッシュを確認します。

12. ドメインを接続し、信頼されたHTTPSを設定し、Giteaの公開URL設定を更新し、生成されたHTTPSクローンリンクが意図したアドレスを使用していることを確認します。

13. VPSを一度再起動し、Giteaが自動的に管理者、テストリポジトリ、コミット履歴、鍵、設定を保持したまま戻ってくることを確認します。

14. オフサーバーバックアップを作成し、重要なソースコードに依存する前にテストリストアを実行します。

セットアップコマンドは意図的にウェブページとは別になっています。公開インストールウィザードはすでにロックされているため、インターネットの訪問者は所有者が行う前に最初の管理者を作成して新しいインスタンスを主張することはできません。また、管理者がすでに存在する場合、コマンドは停止します。

VPSリソースに表示されているSSHユーザー名とポートを使用してください。すべてのサーバーがrootまたはポート22を使用するとは限りません。管理に使用されるVPS SSH接続は、GiteaのSSH Gitエンドポイントであるポート2222とは異なります。

アプリケーションイメージには何が含まれていますか？

Giteaアプリケーションイメージは、管理されたソースコードホスティングサービスではなく、持続可能な単一サーバーの出発点を含みます。 配信の境界は、通常のチーム使用の前に構成する必要があるものを決定します。

アプリケーションイメージによって配信されるもの	ユーザー管理または含まれていないもの
イメージ用に承認されたGitea Community Editionの安定版リリース	自動Giteaアップグレード
UbuntuベースのVPS環境	管理されたオペレーティングシステム管理
公式コンテナ内でローカルSQLiteデータベースを使用して実行されるGitea	外部PostgreSQLまたはMySQLサービス
ロックされたインストールページ	公開ウェブインストールウィザード
最初の管理者を作成するためのプライベートSSHコマンド	事前に作成された管理者または固定パスワード
デフォルトで無効になっている登録	自動チームメンバーのプロビジョニング
ループバックポート`3000`上のウェブバックエンド	公開HTTP露出、ドメイン登録、リバースプロキシ、自動HTTPS
ポート`2222`上のSSH Git	事前インストールされたユーザーSSHキー
持続的なリポジトリ、データベース、設定、およびアプリケーションデータ	自動オフサーバーバックアップ
通常のVPS再起動後のサービス回復	高可用性または自動フェイルオーバー
標準のGiteaコラボレーション機能	管理されたランナー、CI容量、SMTP、OAuth、LDAP、または外部ストレージ

このイメージにはサンプルリポジトリ、組織、ユーザー、ランナー、パッケージ、サードパーティの資格情報、メール配信、ドメイン、またはブラウザが信頼する証明書は含まれていません。また、リソースの詳細にアプリケーションシークレットを公開することもありません。

最初の管理者セットアップはどのように機能しますか？

最初の管理者は認証されたVPS SSHセッションを通じて作成され、Giteaの公開インストールページはロックされたままです。 これにより、未初期化のウェブインストーラーがインターネットからアクセス可能で、意図しない訪問者が最初にセットアップを完了するという一般的なレースを防ぎます。

アプリケーションイメージは配信前にデータベースと設定を準備します。これにより、Giteaのインストールロックが有効になり、公開ユーザー登録が無効になります。次に、管理者セットアップコマンドがアプリケーション環境内でGiteaの公式管理コマンドを実行します。

セットアッププロセスは以下の特性を持つべきです：

ユーザー名とメールアドレスをインタラクティブに尋ねます。
Giteaの公式CLIに24文字のランダムパスワードを生成させ、選択したパスワードをコマンドライン引数に配置しないようにします。
一時パスワードは現在のSSHターミナルでのみ表示され、シェル履歴、ファイル、またはログには書き込まれません。
最初のウェブログイン時にパスワード変更を要求します。
最初の管理者が存在した後に別の管理者を作成することを拒否します。
個人アクセストークンやSSHキーを生成しません。
Giteaの内部シークレットを印刷しません。

サインイン後は、サイト管理およびユーザー登録ポリシーを確認してください。登録はデフォルトでオフになっているため、未知のインターネットユーザーがアカウントを作成することはできません。管理インターフェースから承認されたユーザーを作成するか、オープン登録が意図的な要件であり、悪用防止計画がある場合はポリシーを変更できます。

一時的または最終的な管理者パスワードをチャット、チケット、または共有シェルトランスクリプトを通じて送信しないでください。パスワードを変更した後は最初のSSHセッションを閉じてください。運用上の所有権が必要な場合にのみ、2番目の管理者を追加し、実用的な場合は日常のGit作業に別の通常のアカウントを使用してください。

HTTPS GitとSSH Gitはどのように異なりますか？

HTTPS Gitは信頼されたHTTPSドメインの背後にあるGiteaウェブエンドポイントを使用し、SSH Gitは専用のGitea SSHサービスとアカウントレベルの公開鍵を使用します。両方とも通常のクローン、フェッチ、プル、プッシュ操作をサポートしていますが、認証とトランスポートの設定は異なります。

方法	初期アドレスパターン	認証	セットアップ後の最適な使用法
初期ウェブインターフェース	`http://127.0.0.1:3000` SSHトンネル経由	Giteaのユーザー名とパスワード	最初のログイン、パスワード変更、プライベートセットアップ
通常のウェブインターフェース	`https://git.example.com`	Giteaのユーザー名とパスワード	ドメイン設定後のリポジトリの閲覧と管理
HTTPS Git	`https://git.example.com/<owner>/<repo>.git`	Gitクライアント用の個人アクセストークンを優先	ドメインと信頼されたHTTPS設定後のウェブベースのGitトランスポート
SSH Git	`ssh://git@<server-ip>:2222/<owner>/<repo>.git`	Giteaアカウントに追加されたSSH公開鍵	開発者Gitクライアントや管理されたキーを使用した自動化に便利
VPSシステムSSH	リソース固有のホストとポート	VPS SSHキーまたは現在のサーバー資格情報	サーバー管理と最初の管理者セットアップ、リポジトリアクセスではない

SSH Gitの場合：

ワークステーションでSSHキーを作成または選択します。
Giteaにサインインし、アカウント設定で公開鍵を追加します。
リポジトリページからSSHクローンアドレスをコピーします。
最初の接続時にホストフィンガープリントを確認し、予期しないキーを確認せずに受け入れないようにします。
プライベートキーをクライアントに保持し、適切なファイル権限で保護し、必要に応じてパスフレーズを使用します。

Gitea SSH GitはGiteaウェブパスワードを要求しないはずです。ポート2222はリポジトリサービスに属し、サーバーシェルを提供しません。

HTTPS Gitの場合、クライアントまたは統合に必要な権限のみを持つ個人アクセストークンを作成します。シェル履歴に残るコマンドにトークンを直接埋め込むことは避けてください。Git資格情報ヘルパーまたはオペレーティングシステムに適したシークレットストアを使用してください。

ドメインとHTTPSを追加する理由は何ですか？

ドメインとブラウザが信頼するHTTPSは、ウェブ資格情報とHTTPS Gitトラフィックを保護し、インスタンスに安定した公開アイデンティティを与えます。 このイメージはポート3000をVPSループバックインターフェースに保持しているため、リバースプロキシを意図的に構成するまでウェブサービスは公開されません。

公式Giteaリバースプロキシガイドは、Giteaが一般的なプロキシの背後でどのように機能するかを説明しています。生産セットアップには通常、以下が含まれます：

git.example.comのようなDNSレコードがVPSを指す。
ポート80および443でリッスンするリバースプロキシ。
ドメイン用のブラウザが信頼するTLS証明書。
HTTPからHTTPSへのリダイレクト。
プロキシ構成に一致する転送されたホスト、クライアントアドレス、およびプロトコルヘッダー。
Giteaの公開ROOT_URLおよびドメイン設定が最終的なHTTPS URLに更新される。
SSH_DOMAINおよび表示されるSSHポートが更新され、リポジトリクローンの指示が正確に保たれる。

アドレスを変更した後は、以下のすべてを確認してください：

サインインページが証明書警告なしに読み込まれる。
Giteaによって生成されたリンクが古いIPアドレスではなくHTTPSドメインを使用する。
HTTP GitクローンとプッシュがHTTPSを通じて機能する。
SSHクローンリンクが正しいドメインとポートを表示する。
後で構成された場合、ウェブフックとOAuthコールバックURLが意図した公開アドレスを使用する。
大きなプッシュがリバースプロキシのボディやタイムアウト制限によって失敗しない。

アプリケーションイメージは、ドメインを登録したり、証明書を発行したりしません。これらのステップはユーザー管理であり、最終的なホスト名とDNSアカウントはサイト所有者に属します。

ユーザーとリポジトリアクセスをどのように整理すべきですか？

1つの管理者アイデンティティを共有するのではなく、個別のアカウント、組織チーム、リポジトリの権限、SSHキー、およびスコープ付きトークンを使用してください。 Giteaはプライベートおよびパブリックリポジトリをホストできますが、管理者は各リソースを誰が発見し、読み取り、書き込み、レビュー、管理できるかを決定する必要があります。

実用的な小規模チームのベースラインは：

意図的な理由がない限り、公開登録を無効にしておきます。
各人に個別のアカウントを与えます。
サーバーおよびサービスの所有者のために管理者アクセスを予約します。
関連するリポジトリのために組織を作成し、権限グループのためにチームを作成します。
各役割に必要な最小限のリポジトリ権限を付与します。
重要なブランチに対してブランチ保護およびレビュー規則を使用します。
管理者パスワードではなく、デプロイキーまたはスコープ付き個人アクセストークンを自動化に使用します。
アクセスがもはや必要でない場合は、アカウント、キー、トークンを迅速に削除します。
アクセスモデルに合う場合は、特権ユーザーに対して二要素認証を有効にします。
組織、リポジトリ、ウェブフック、OAuth、およびトークンの所有権を定期的に確認します。

後でSMTP、OAuth、LDAP、またはOpenID Connectを接続する場合、それは別の生産変更として扱います。統合に依存する前に、アカウントリンク、回復、オフボーディング、管理者アクセス、および障害動作をテストしてください。ベースイメージにはこれらのサービスやその資格情報は含まれていません。

Giteaバックアップは何を保護する必要がありますか？

完全なGiteaバックアップは、データベース、Gitリポジトリ、設定、アプリケーションシークレット、およびインスタンスが使用する添付ファイル、LFSオブジェクト、パッケージ、リリース、アバター、またはその他の保存データを保護する必要があります。 Gitリポジトリのみをコピーすることでは、ユーザー、権限、問題、プルリクエスト、トークン、ウェブフック、およびサービス設定を再構築するには不十分です。

公式Giteaバックアップおよびリストアドキュメントは、gitea dumpワークフローを説明し、サービスが一緒に変更される可能性のある複数のデータ層を含むことを警告しています。一貫したバックアップには調整が必要であり、リポジトリ操作が完了したと報告するアプリケーションデータベースが、リポジトリコピーが以前の状態をキャプチャしている場合、不完全な回復ポイントを生成する可能性があります。

バックアップ計画は以下を定義する必要があります：

レイヤー	例	重要性
データベース	ユーザー、権限、問題、プルリクエスト、設定、トークン	アプリケーションの状態と関係を再構築します
Gitリポジトリ	コミット、ブランチ、タグ、Gitオブジェクト	ソース履歴を保持します
設定とシークレット	公開URL、サービス設定、`SECRET_KEY`、内部トークン	暗号化データを読み取り可能にし、動作を一貫させます
アプリケーションデータ	添付ファイル、アバター、LFS、パッケージ、リリースアセット、インデックス	通常のGitオブジェクト以外のコンテンツを保持します
回復手順	バージョン、所有権、フック再生成、検証ステップ	保存されたファイルを使用可能な復元サービスに変えます

回復コピーはVPSの外に保存してください。プライベートソースコード、資格情報、トークン、個人データ、または内部設定を含む場合は暗号化してください。1つ以上の回復ポイントを保持し、バックアップの完了を監視し、別の環境でリストアをテストしてください。

通常のVPS再起動は持続性を証明しますが、回復性を証明するものではありません。偶発的な削除、リポジトリの破損、アップグレードの失敗、資格情報の侵害、ファイルシステムの損失、VPSの削除、または攻撃者がライブデータとローカルバックアップファイルの両方を削除することから保護するものではありません。

SSH、パッチ適用、監視、回復所有権に関する広範なサーバーメンテナンスのベースラインについては、VPS管理：実用ガイドを参照してください。

Giteaをどのように更新すべきですか？

Giteaを制御されたアプリケーション変更として更新します：リリースノートを読み、復元可能なバックアップを作成し、デプロイメントタイプを保持し、その後リポジトリと認証を確認します。このイメージは、固定された安定リリースを使用しており、浮動するタグではないため、再起動してもアプリケーションバージョンが静かに変更されることはありません。

更新前に：

ソースおよびターゲットバージョンのGiteaリリースおよびアップグレードノートを読みます。
レビューなしでバージョン間をスキップするのではなく、サポートされているアップグレードパスを確認します。
オフサーバーバックアップを作成し、確認します。
現在のコンテナイメージ、設定、公開URL、SSH設定、およびストレージ所有権を記録します。
データベースの移行やバックアップの一貫性がダウンタイムを必要とする場合があるため、メンテナンスウィンドウを計画します。

更新後：

コンテナが正常な状態に達していることを確認します。
通常のアカウントと管理者アカウントでサインインします。
HTTP(S)およびSSHを通じてクローン、プル、プッシュします。
テストリポジトリで問題とプルリクエストを開きます。
インスタンスが実際に使用しているウェブフック、パッケージ、LFS、メール、および認証統合を確認します。
生成されたクローンURLがまだ正しいドメインとポートを使用していることを確認します。
ユーザー、リポジトリ、設定、シークレットが変更を生き残ったことを確認します。

Giteaのルートフルおよびルートレスコンテナレイアウト間をカジュアルに切り替えないでください。公式Dockerドキュメントは、それらのストレージとSSHの動作が異なることに注意しています。アプリケーションイメージによって選択されたデプロイメントモデルを保持してください。移行およびロールバック計画がない限り。

GiteaにはどれくらいのVPS容量が必要ですか？

Giteaの容量は、ユーザーの同時接続、リポジトリの数とサイズ、Git操作パターン、パッケージ、LFS、インデックス作成、自動化、およびデータ保持要件に依存します。購入フローで対象となるプランを選択し、実際のワークロードを監視し、持続的なCPU、メモリ、ディスク、またはI/O圧力が現れた場合は大きな構成に移行します。

公式Giteaプロジェクトは、小規模チームのインストールを比較的軽量と説明していますが、その声明はすべてのリポジトリワークロードの容量を定義するものではありません。大きなモノリポジトリ、頻繁なクローン、大きなバイナリアセット、パッケージストレージ、検索インデックス作成、および自動化ジョブは、リソースプロファイルを大幅に変更する可能性があります。

ワークロード	容量の考慮
いくつかの小さなソースリポジトリ	エントリ検証ワークロードに適しています
小規模開発チーム	同時ウェブおよびGit操作を測定します
大規模リポジトリ履歴	ディスクスペース、バックアップ時間、およびクローントラフィックを計画します
Git LFSまたはパッケージレジストリ	通常のGitオブジェクトとは別にストレージと転送を計画します
多くのウェブフックまたは統合	キュー、失敗、および下流の可用性を監視します
Gitea Actions	ランナー容量は別であり、ベースイメージには含まれていません
外部データベースまたはオブジェクトストレージ	別途設計および運用されるアーキテクチャが必要です

メモリ圧力、CPU飽和、ファイルシステム容量、inode使用、SQLiteロック動作、コンテナ再起動、リクエストレイテンシ、失敗したGit操作、バックアップの所要時間、リストアの所要時間を監視してください。最小購入ゲートは検証された出発点であり、無制限のリポジトリやユーザーの約束ではありません。

避けるべき一般的な間違い

ほとんどの初期のGiteaの失敗は、プリインストールされたリポジトリサービスを完全に管理されたプラットフォームとして扱うことから来ています。 これらの間違いを避けてください：

インストールウィザードを公開したままにすること。 SSH管理者セットアップフローを使用し、インストールロックを有効にしておきます。
悪用計画なしで公開登録を開放すること。 オープンサインアップが意図的でない限り、登録を無効にしておきます。
ポート3000を公開HTTPとして露出させること。 ループバックに保持し、通常のウェブおよびHTTPS Git使用の前に信頼されたHTTPSを持つドメインを追加します。
ポート2222をVPSシェルアクセスと混同すること。 これはGitea SSH Gitエンドポイントであり、サーバーシェルを提供しません。
1つの管理者アカウントを共有すること。 個別のアカウントと最小権限を使用します。
トークンをシェル履歴やリポジトリファイルに置くこと。 適切な資格情報またはシークレットストアを使用します。
Gitリポジトリのみをバックアップすること。 データベース、設定、シークレット、添付ファイル、LFS、パッケージ、および回復手順も保護します。
唯一のバックアップを同じVPSに保持すること。 暗号化された回復コピーをサーバーの外に保存します。
浮動コンテナタグを使用すること。 テストされた安定版リリースを固定し、意図的に更新します。
最小容量がCIや大きなバイナリをカバーすると仮定すること。 ランナー、パッケージ、LFS、モノリポジトリ、および重い同時接続は別途サイズ設定が必要です。
Giteaを更新せずに公開URLを変更すること。 ROOT_URL、ドメイン、SSHドメイン、クローンリンク、コールバック、およびウェブフックを確認します。
リストアテストなしで更新すること。 一度もリストアされていないバックアップは未検証の回復計画です。

FAQ

Giteaを手動でインストールせずに自己ホスティングできますか？

はい。VoyraCloud Giteaアプリケーションイメージは、対象となるCloud VPSまたはResidential IP VPS上にプリインストールされたCommunity Editionインスタンスを提供します。あなたは依然として最初の管理者を作成し、リポジトリアクセスを構成し、ドメインとHTTPSを接続し、ユーザーを管理し、アップデートとバックアップを所有します。

最初の管理者はなぜSSHを通じて作成されるのですか？

SSHは管理者作成ステップをVPSへのアクセスの背後に保持し、インターネット訪問者が公開されたインストールウィザードを主張するのを防ぎます。 公開インストールページは配信前にロックされており、セットアップコマンドはすでに1人の管理者が存在する場合、別の管理者を作成することを拒否します。

ポート`3000`をインターネットに直接公開できますか？

いいえ。アプリケーションはポート3000をVPSループバックインターフェースにバインドし、最初のログインはSSHトンネルを使用します。 ドメインを接続し、リバースプロキシとブラウザが信頼するHTTPSを構成し、ウェブサービスを公開する前にGiteaの公開URL設定を更新してください。

VPS SSHとGitea SSH Gitの違いは何ですか？

VPS SSHはLinuxサーバーを管理し、Gitea SSH GitはGiteaアカウントに添付されたキーを使用してリポジトリデータを転送します。 VPSはリソースに表示されているSSHホストとポートを使用し、Gitea SSH Gitはgitユーザーとポート2222を使用します。

HTTPS Gitにはパスワードとトークンのどちらを使用すべきですか？

クライアントまたは統合に必要な権限のみを持つ個人アクセストークンを使用してください。 リポジトリ、スクリプト、またはシェル履歴エントリに埋め込むのではなく、適切な資格情報ヘルパーに保存してください。

公開ユーザー登録は有効ですか？

いいえ。アプリケーションイメージはデフォルトで自己登録を無効にしています。 管理者は承認されたユーザーを作成するか、悪用、メール検証、およびアクセス制御要件を評価した後に登録ポリシーを意図的に変更できます。

イメージにはGitea Actionsランナーが含まれていますか？

いいえ。ベースイメージはActionsランナーをプロビジョニングまたは運用しません。 ランナーの実行容量、隔離、シークレット、ネットワークアクセス、およびメンテナンスには別途設計が必要です。

何をバックアップする必要がありますか？

データベース、Gitリポジトリ、設定、アプリケーションシークレット、添付ファイル、LFSオブジェクト、パッケージ、リリース、およびその他の保存されたアプリケーションデータを保護してください。 VPSの外にコピーを保持し、完全なリストアをテストしてください。

VoyraCloudはGiteaを自動的に更新しますか？

いいえ。新しいVPSリソースは、イメージ用に承認された安定リリースを受け取り、各所有者が後の更新を制御します。 公式のアップグレードノートを読み、復元可能なバックアップを作成し、変更後にGitおよび認証ワークフローをテストしてください。

GiteaにはResidential IP VPSが必要ですか？

いいえ。Cloud VPSはソースコードサービスのための通常の一般目的の選択肢です。 Residential IP VPSは、広範なワークロードがそのネットワーク特性を特に必要とする場合に技術的にサポートされていますが、住宅のアイデンティティは通常のGitホスティングを自体で改善するものではありません。

結論

VPS上でGiteaを自己ホスティングすることで、開発者や小規模チームはリポジトリ、アカウント、コラボレーションデータ、ネットワークアクセス、アップデート、および回復を制御できます。 VoyraCloudアプリケーションイメージは、ロックされたインストールページ、プライベートな最初の管理者セットアップ、HTTPSおよびSSH Gitアクセス、持続的なローカルデータを提供する固定された安定Gitea環境を提供することで、初期デプロイメントを短縮します。

その出発点には所有者が必要です。信頼されたHTTPSを追加し、個別のアカウントとスコープ付き資格情報を使用し、登録をアクセスポリシーに合わせて維持し、容量を監視し、更新を固定し、テストされたオフサーバーバックアップを維持してから、サービスを重要なインフラストラクチャとして扱ってください。

サービスの前にドメインとリバースプロキシレイヤーを追加する方法については、VPS上のNginx Proxy Managerのガイドを参照してください。

VoyraCloud Gitea用アプリケーションイメージを使用して、プリインストールされたVPS環境から始めながら、ソースコードサービスをあなたの管理下に保ちましょう。