開発

code-serverの使い方:導入・認証・拡張機能・HTTPS公開の手順【2026年10月】

code-serverの使い方:導入・認証・拡張機能・HTTPS公開の手順【2026年10月】

code-serverは、VS Codeをサーバー上で動かし、手元のブラウザから開いて使うためのオープンソースソフトウェアです。この記事では、Linuxへのインストールと自動起動、Dockerでの起動、設定ファイルconfig.yamlでのパスワード管理、SSHトンネルやAWS Session Managerを使った非公開での接続、CaddyによるHTTPS化までを、コピーして動かせるコマンド付きで解説します。拡張機能がOpen VSXに限られる制約と、GitHub Codespacesなどとの使い分けも扱います。数値と版番号は2026年10月5日時点の公式ドキュメントとGitHubリリースで確認した値です。

まとめ:code-serverは自前サーバーで動かすブラウザ版VS Code

code-serverの導入は「install.shで入れる→systemdで常駐させる→config.yamlのパスワードでログインする」の3手順で終わります。既定では127.0.0.1の8080番ポートでしか待ち受けないため、インストール直後の状態は外部から見えません。外から使うときは、まずSSHのポートフォワードかAWS Session Managerでつなぎ、インターネットに公開する場合だけCaddy等でHTTPS化します。

最大の落とし穴は拡張機能です。Microsoftのマーケットプレイスは規約上使えず、Open VSXに登録された拡張だけが標準で入ります。社内の閉じたネットワークで、1人1台のサーバーに開発環境を集約したい場合は有力な選択肢です。逆に、Microsoft製の非公開拡張やLive Shareを前提にしたチームには勧めません。

code-serverの仕組みと2026年10月時点の最新版4.140系の要点

code-serverはCoder社が開発し、MITライセンスでGitHubのcoder/code-serverリポジトリに公開されています。スター数は2026年10月時点で約7.9万です。VS Codeのオープンソース部分を取り込み、セルフホスト向けの変更をパッチとして当てる構造になっています。

ブラウザとサーバーをWebSocketでつなぐ構成と必要スペック1GB・2コア

エディタ本体・拡張機能・ターミナル・ビルド処理はすべてサーバー側で動き、ブラウザは画面の描画と入力の受け渡しだけを担います。両者の通信はWebSocketです。そのため途中にプロキシやロードバランサーを挟む場合は、WebSocketを通す設定が前提になります。

公式の要件ページが示す最低スペックは、メモリ1GB・CPU2コアです。これは起動の下限であり、TypeScriptの型チェックやDockerのビルドを同じサーバーで回すなら、メモリは4GB以上を見込むのが現実的です。AWSで動かす場合のインスタンスタイプと料金の考え方はAmazon EC2の仕組みとインスタンスタイプの解説で整理しています。

版番号の読み方:4.140.0はVS Code 1.140.0を同梱した系列

code-serverの版番号は、同梱するVS Codeの版と対応しています。2026年10月5日時点の最新版はv4.140.0(2026年10月1日公開)で、リリースノートの内容は「Code 1.140.0への更新」です。GitHubのリリース一覧には、8月27日の4.135.0から10月1日の4.140.0までの約5週間に6本が並んでおり、本家VS Codeの週次リリースにほぼ追随しています。

中身のVS Codeの版が分かれば、新機能や設定項目は本家のリリースノートで追えます。本家の版番号の確認方法と週次リリースの仕組みはVS Codeの最新バージョンと週次リリースの解説を参照してください。

インストール手順:install.sh・Docker・systemd常駐化の3つの方法

Linux・macOS・FreeBSDでは公式のインストールスクリプトが標準です。コンテナで隔離したい場合はDockerイメージを使います。用途別に手順を示します。

install.shのdry-runで実行内容を確かめてからLinuxに入れる手順

公式のインストール手順では、スクリプトがOSのパッケージマネージャーを検出し、Debian・Ubuntuなら.deb、Fedora・RHEL系なら.rpmを入れます。実行前に--dry-runで、何が実行されるかを確認できます。

# 実行される処理を表示するだけ(何もインストールしない)
curl -fsSL https://code-server.dev/install.sh | sh -s -- --dry-run

# 実際にインストールする
curl -fsSL https://code-server.dev/install.sh | sh

# ログインユーザーの権限で常駐させ、OS起動時にも自動起動する
sudo systemctl enable --now code-server@$USER

# 状態確認
systemctl status code-server@$USER

常駐後は、サーバー上でhttp://127.0.0.1:8080を開くとログイン画面が出ます。配布物があるのはamd64とarm64で、それ以外のアーキテクチャではnpm経由のビルドに切り替わります。アップデートは公式のアップグレード手順のとおり、新しい版を上書きインストールするだけです。設定や拡張機能は~/.local/share/code-serverに残ります。

Dockerイメージcodercom/code-serverで設定を永続化する手順

公式イメージはDocker Hubのcodercom/code-serverで、amd64とarm64に対応しています。公式手順のコマンドは、設定・拡張機能・作業ディレクトリをホスト側にマウントし、ホストと同じUID/GIDで動かす形です。

mkdir -p ~/.config
docker run -it --name code-server -p 127.0.0.1:8080:8080 \
  -v "$HOME/.local:/home/coder/.local" \
  -v "$HOME/.config:/home/coder/.config" \
  -v "$PWD:/home/coder/project" \
  -u "$(id -u):$(id -g)" \
  -e "DOCKER_USER=$USER" \
  codercom/code-server:latest

-p 127.0.0.1:8080:8080のように待受先をループバックに限定している点を、そのまま残してください。-p 8080:8080と書くと全インターフェースで公開され、クラウドのセキュリティグループ次第でログイン画面がインターネットから見える状態になります。本番ではlatestではなく4.140.0のように版を固定したタグを指定し、更新はリリースノートを確認してから行います。

Windows版tar.gzの配布開始とinstall文書が未更新という食い違い

Windowsへの対応は、2026年9月に状況が変わりました。v4.137.0(2026年9月11日公開)のリリースノートに「Windows releases are now available」と記載され、最新のv4.140.0にもcode-server-4.140.0-windows-amd64.tar.gzが含まれています。

ところが公式のインストール文書のWindows節は、2026年10月5日時点でも「Windows版は公開していない」という記述のまま、GitHubのissue 1397へ誘導しています。配布物はあっても手順書が追いついていない段階なので、業務で使うサーバーには文書化されたLinux版を選んでください。Windows機で使いたいだけなら、WSL上のLinuxに入れるのが確実です。

config.yamlの設定:パスワード認証・ハッシュ化・待受アドレスの変更

認証まわりの変更は、初回起動時に生成される設定ファイルの編集と再起動で行います。

初回起動で生成されるconfig.yamlの既定値とパスワードの確認場所

設定ファイルの場所は~/.config/code-server/config.yamlです。公式FAQによると、既定値はループバックの8080番で待ち受け、パスワード認証を有効にし、TLSは使わない構成です。

# ~/.config/code-server/config.yaml(初回起動時に自動生成)
bind-addr: 127.0.0.1:8080
auth: password
password: 9f3c...(設定ファイルごとにランダム生成)
cert: false

ログイン用のパスワードは、このpasswordの値です。変更するときは値を書き換え、sudo systemctl restart code-server@$USERで再起動します。bind-addrを0.0.0.0:8080に変えると外部から直接つながりますが、TLSなしの平文でパスワードが流れるため、この変更単独では行わないでください。

hashed-passwordでargon2ハッシュを保存しログイン試行制限を把握

設定ファイルに平文のパスワードを置きたくない場合は、hashed-passwordにargon2のハッシュを書きます。hashed-passwordはpasswordより優先されます。

# ハッシュを生成する(Node.jsのnpxを使用)
echo -n "ここに実際のパスワード" | npx argon2-cli -e

# config.yaml 側は password を消し、引用符で囲んで書く
auth: password
hashed-password: "$argon2i$v=19$m=4096,t=3,p=1$...(生成された文字列)"

Docker Composeの環境変数で渡すときは、$をすべて$$に置き換える必要があります。総当たりへの備えとして、ログイン試行は1分あたり2回、それに加えて1時間あたり12回までに制限されています。とはいえ利用者全員が1つのパスワードを共有する方式なので、個人の識別や失効はできません。この弱点を補う方法は次の章で扱います。

外部から安全に接続する方法:SSHトンネル・SSM・HTTPS化の使い分け

公式の利用ガイドが第一に推奨するのは、SSHのポートフォワードです。ポートを公開しないまま手元のブラウザから使えるため、最初はこの方法を選び、iPadなどSSHクライアントのない端末で使う必要が出たときにHTTPS公開を検討する順番が安全です。

SSHポートフォワードとAWS Session Managerで公開せずに接続する手順

SSHで入れるサーバーなら、手元のPCで次のコマンドを実行し、ブラウザでhttp://localhost:8080を開きます。dev-serverは~/.ssh/configに定義したホスト名です。

# -N はリモートでシェルを起動せず、転送だけを行う指定
ssh -N -L 8080:127.0.0.1:8080 dev-server

EC2で動かす場合は、SSHの22番ポートも開けずに済むAWS Session Managerが使えます。AWS公式のセッション開始手順にあるポートフォワード用ドキュメントAWS-StartPortForwardingSessionを指定します。

# 手元に AWS CLI と Session Manager プラグインが必要
aws ssm start-session \
  --target i-0123456789abcdef0 \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["8080"],"localPortNumber":["8080"]}'

インバウンドを全閉にでき、接続者はIAMの権限で絞れます。インスタンス側に必要なSSM Agentの導入と権限設定はSSM AgentとSession Manager接続の解説を参照してください。

CaddyとLet’s EncryptでHTTPS化してインターネットへ公開する設定例

独自ドメインで公開する場合は、code-serverの前段にリバースプロキシを置いてHTTPSを終端させます。公式ガイドが示すCaddyの設定は2行で、Let’s Encryptの証明書取得と更新もCaddyが自動で行います。

# /etc/caddy/Caddyfile
code.example.com {
  reverse_proxy 127.0.0.1:8080
}

編集後にsudo systemctl reload caddyで反映します。サーバーの80番と443番を外部に開け、ドメインのDNSがサーバーのIPを向いていることが前提です。NGINXで組む場合はUpgradeとConnectionヘッダーを転送しないとWebSocketが切れ、画面が表示されてもエディタが動きません。プロキシを挟む構成そのものの考え方はリバースプロキシの仕組みと導入判断で解説しています。

OAuth2 ProxyやCloudflare Accessで共有パスワードを補う構成

インターネットに公開するなら、共有パスワードだけに頼らない構成にする方針です。公式ガイドは、Pomerium・OAuth2 Proxy・Cloudflare Accessといった認証付きプロキシを前段に置き、Googleアカウント等でのログインを挟む方法を挙げています。前段で個人を識別できれば、退職者の失効や接続記録の確認も個人単位で行えます。

この構成をとる場合、code-server側の認証はauth: noneに変えたくなりますが、前段のプロキシを経由しない経路が残っていないかを先に確かめてください。サーバーの受信ポートを開けずに公開できるCloudflare Tunnelと組み合わせると、経路を1本に絞れます。仕組みと設定はCloudflare Tunnelの仕組みとcloudflaredの設定手順にまとめています。

拡張機能の制約:Open VSXのみ対応でMicrosoft製拡張が入らない理由

使い慣れた拡張機能が検索しても見つからない原因は、不具合ではなくマーケットプレイスの規約にあります。

Microsoftマーケットプレイスの利用規約とOpen VSXへの切り替え

VS Codeの本体はオープンソースですが、拡張機能のマーケットプレイスとMicrosoftが公開する拡張の多くはオープンソースではありません。公式FAQによると、マーケットプレイスの利用規約はMicrosoftの製品以外からの利用を認めておらず、code-serverは代わりにEclipse財団系のOpen VSX Registryを使います。

環境変数EXTENSIONS_GALLERYで接続先のマーケットプレイスを差し替えることは技術的には可能です。ただし、Microsoftのマーケットプレイスへ向ける設定は規約違反になるため、公式も強く非推奨としています。社内で使う環境で規約違反の設定を入れる判断はしないでください。FAQでは、Live Shareと、Remote系の拡張(SSH・Containers・WSL)も使えないと明記されています。

VSIXの手動インストールと動かない拡張の見分け方・代替の探し方

拡張機能はサイドバーから入れるほか、コマンドラインでも操作できます。Open VSXにない拡張は、配布元のGitHubリリースなどからVSIXファイルを取得して入れます。

# Open VSX から拡張IDを指定してインストール
code-server --install-extension wesbos.theme-cobalt2

# ダウンロードしたVSIXファイルからインストール
code-server --install-extension ./my-extension-1.2.3.vsix

# インストール済みの拡張を一覧表示
code-server --list-extensions

拡張の保存先は~/.local/share/code-server/extensionsです。導入前の確認は、Open VSXで拡張IDを検索し、登録の有無と最終更新日を見る手順で足ります。VSIXで入れても、Microsoftのサービスへの認証を前提にする拡張は動かないことがあります。チームで必須の拡張を先に洗い出し、導入前に1つずつ確かめてください。

組み込みポートプロキシでWebアプリの開発サーバーを確認する方法

code-serverの上でReactやViteの開発サーバーを起動した場合、組み込みのプロキシ経由で画面を確認できます。3000番で動くアプリなら/proxy/3000/を開くだけで、code-serverのログイン認証がそのまま適用されます。

このプロキシはパスの先頭の/proxy/3000を取り除いてアプリへ渡す仕様です。絶対パスでリソースを読むフレームワークで表示が崩れたら、/absproxy/3000/に切り替え、アプリ側のベースパスも合わせてください。

code-serverを採用する条件と見送る場面:Codespaces等との比較

公式FAQの記述をもとに類似製品との違いを整理し、code-serverを選ぶ条件を言い切ります。

Codespaces・OpenVSCode-Server・Coderとの違いの比較表

製品 提供形態 拡張機能の入手先 向いている用途
code-server セルフホスト・無料・OSS Open VSX 個人や少人数が自前サーバーで使う
OpenVSCode-Server セルフホスト・OSS Open VSX VS Codeをほぼそのままブラウザで使う
GitHub Codespaces クラウドサービス・有料 Microsoft公式 GitHub上のリポジトリを即座に開く
Coder セルフホスト・チーム向け ワークスペース次第 Terraformで開発環境を一括配布する

OpenVSCode-ServerがVS Codeをそのままブラウザに載せるのに対し、code-serverはパスワード認証やポートプロキシなどセルフホスト向けの機能を足しています。Coderはワークスペースの中でcode-serverを動かす、チーム向けの上位製品です。ローカルのVS Codeでコンテナ開発環境をそろえる方法との違いはDev Containerの仕組みとメリットの解説と読み比べると判断しやすくなります。

採用する条件:社内ネットワーク限定・端末を選ばない・1人1台構成

code-serverが向くのは、次の条件がそろう場合です。

  • ソースコードを手元の端末に置きたくない(端末紛失時の情報漏えいを避けたい)
  • ビルドやテストに手元のPCより強いマシンを使いたい
  • Chromebookやタブレットなど、VS Codeを入れにくい端末からも作業したい
  • 開発環境を社内ネットワークやVPCの中に閉じ、SaaSへの依存を避けたい

効果が大きいのは最初の2つです。構成は1人1台のサーバー(またはVM)とし、接続はSession ManagerかSSHトンネルに絞ります。

見送る場面:Live Share前提のチームと1台を多人数で共有する構成

次のどれかに当てはまるなら、code-serverは採用しません。1つ目は、Live Shareでの共同編集やRemote-SSH拡張など、Microsoft製の非公開拡張が作業の前提になっているチームです。この場合はGitHub CodespacesやローカルのVS Codeを選びます。

2つ目は、1台のサーバーのcode-serverを複数人で共有する構成です。パスワードは1つで、全員が同じOSユーザーとしてファイルとターミナルを操作することになり、誰が何をしたかを区別できません。公式FAQもマルチテナントには1ユーザー1VMを推奨しています。10人以上に開発環境を配る規模なら、code-serverを個別に立てるのではなく、Coderのような配布の仕組みを検討する段階です。

社内の開発環境としてEC2上に構築する際の構成と外注時に決める項目

EC2で社内向けに構築する場合、プライベートサブネットにインスタンスを置き、受信ポートは全閉、接続はSession Managerのポートフォワードという構成が基本形です。ここに、EBSのスナップショットによるバックアップ、夜間の自動停止によるコスト削減、拡張機能の許可リストを加えると、業務で使える水準になります。

構築を外部に依頼する場合は、利用人数、扱うソースコードの機密度、必須の拡張機能の一覧、接続元(社内ネットワーク限定か在宅も含むか)の4点を最初に決めておくと、見積もりと構成案がぶれません。一創では、こうした開発基盤を含むクラウド環境の設計と構築をAWS・Google Cloud・Azureのインフラ構築支援として請け負っています。

よくある質問

code-serverの導入と運用で寄せられやすい質問をまとめました。

code-serverは無料で使えますか?

無料で使えます。code-serverはMITライセンスのオープンソースソフトウェアで、商用利用も可能です。費用がかかるのは、動かすサーバーやクラウドのインスタンス代、HTTPS公開に使うドメイン代などのインフラ側だけです。

パスワードを忘れたときや変更したいときはどうしますか?

サーバーにログインし、~/.config/code-server/config.yamlのpasswordの値を確認または書き換えます。変更した場合はsudo systemctl restart code-server@$USERで再起動すると反映されます。Dockerで動かしている場合は、マウントしたホスト側の~/.config配下にある同じファイルを編集し、コンテナを再起動してください。

iPadからcode-serverを使えますか?

使えます。公式ドキュメントにはiPad向けの専用ページがあり、ホーム画面に追加するPWAとしての利用方法も案内されています。注意点は証明書で、自己署名証明書はiPadでうまく動かないため、Let’s Encrypt等の正規の証明書でHTTPS化しておくことが必要です。SSHクライアントを使えない端末で使う場合が、HTTPS公開を選ぶ主な理由になります。

アップデートするとき、設定や拡張機能は消えますか?

消えません。公式のアップグレード手順は「新しい版を古い版の上にインストールする」だけで、ユーザーデータは~/.local/share/code-serverに保存されているため引き継がれます。install.shを再実行するか、新しい.debや.rpmを入れ直す方法です。Dockerの場合は版を固定したタグを新しい版に書き換え、同じボリュームをマウントして起動し直します。

ネットワークが切れたら作業中のターミナルはどうなりますか?

一定時間内に再接続すれば、そのまま作業を続けられます。処理はサーバー側で動いているため、切断中もビルドやテストは止まりません。再接続を待つ猶予は既定で10800秒(3時間)あり、config.yamlのreconnection-grace-timeで変えられます。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.04.20 テックブログ Chrome(Gemini)のSkillsとは?使い方・作成手順・利用条件と表示されない時の対処
  2. 2026.09.25 コラム 社会保険加入条件は50人以下の場合どうなる:2027年10月からの段階撤廃と週20時間の判定をシステムで行う要件
  3. 2026.09.25 コラム 最低賃金引き上げ【令和8年度】47都道府県の改定額・発効日と企業の対応手順
  4. 2024.06.11 コラム 個人情報漏えい件数の推移をグラフで解説|最新データと過去最多(約1.9万件)
  5. 2026.06.16 コラム 内部通報制度の改正ポイント|2026年12月1日施行の公益通報者保護法と改正指針への対応

RELATED POSTS 関連記事

目次