ローカルネットワーク間でのファイル共有のために作った5MBのRustファイルサーバー
(saibius.com)開発をしていると、一時的にファイルを共有したい場面がしばしばあります。
例えば、ローカルでファイルを素早く共有したいとき（たとえばAIチェックポイントや学習データなど）、こうしたファイルは大容量なことが多く、既存のクラウドサービス経由の転送は遅いですし、Pythonサーバーのようなものはたまに落ちたり（？）するのが不便で、Curl/Wgetで一時的に共有できるローカルファイルサーバーがあればと思って作りました。
特徴は大きく4つあります。
第一に、クロスプラットフォーム。— これも自分が楽をしたくて作った面はあるのですが、LinuxとWindowsを行き来する自分にとって、同じコマンドを使えることは譲れない欲求でした…
第二に、Web UI。— Apacheスタイルの小さなWebサーバーを標準で内蔵しており、ユーザーが共有したフォルダからファイルをダウンロードしたり、一部のブラウザ対応ファイル（html、txtなど）をそのまま閲覧できるようにしました。
第三に、追加ランタイムのインストール不要。— 当初はexpressサーバーなども検討しましたが、私はLXCなどを使うことが多く、Nodeのようなランタイムを別途インストールするのが面倒でした。WindowsでもVMを起動すると毎回セットアップが煩わしい部分もありました。
第四に、5MB以内のファイルサーバー。— 「ファイル転送」以外をすべて削ぎ落として、実際のファイルサイズを5MB以内に収めました（最も容量が大きいのはLinux x86で4.12MB、1.0.0基準ビルドです）。
実際に自分で使っているプログラムですが、自分で作って自分で使ってみた結果、ISOファイルや大容量画像、あるいはPDFなどを一時的に内部ネットワークで共有するときに便利です。
フォルダ共有の例 : ./saibius –file ./share
Webサイト : https://saibius.com/
GitHub : https://github.com/saibius/docs
P.S. 4,900ウォンで販売中ですが、先着10名に無料キーを提供しています。
https://saibius.com/redeem?key=SAIBIUS-2026-R1 のリンクにアクセスすると自動入力されます :)
20件のコメント
copyparty みたいなものなんでしょうね。
こんにちは。
良い一日をお過ごしでしょうか。
週末の間に用事があり、確認が遅くなってしまいました。
基本的な目的は Copyparty と似た設計になっています。
開発当時はこのようなプロジェクトの存在を知らず、コメントを通じて知ることになりました。
私が考える違いとしては、
私たちのユースケースでは別途ランタイムの導入が難しい
内部ネットワークのサーバーでも使うことがあるため、共有するデバイスでは別途ランタイム（例: Python ランタイム、追加パッケージなど）を使わないように作った点が特徴です。
多くのサーバーには Python が含まれていますが、私たちの環境では LXC のように最小限のパッケージだけで運用する環境のため、この点は環境やユースケースごとに異なると思います。
これからも進化する Saibius であり続けます。
関心をお寄せいただき、ありがとうございます。
良い一日をお過ごしください :)
将来的にAndroidのTermux環境もサポートする予定はありますか？
Androidから別の環境へファイルを送る必要があるとき、crocが使えるならcroc、Webブラウザやcurl、wgetでアクセスしなければならないなら主に Copyparty を使っているのですが、簡単に共有するときはこれも良さそうだと思いました
こんにちは！
よい連休をお過ごしでしょうか？
お待ちいただいていたマイナーアップデート 1.0.0.11 に、Termux(Android) ビルドが追加されました！
アップデートは2月12日に配信されましたが、安定化作業に時間がかかり、ようやく今になって返信できました。
これからも成長し続ける Saibius でありたいと思います。
ご関心をお寄せいただき、ありがとうございます。
よい一日をお過ごしください :)
おお、情報ありがとうございます！
こんにちは！
良い夜をお過ごしでしょうか？
お待ちいただいていたマイナーアップデート 1.0.0.11 に Termux(Android) ビルドを追加して配布する予定です。
当初の予想より少し遅れましたが、Playストアの最新バージョン基準で正常動作を確認しました。
安全な配布に向けて準備中ですので、もう少しだけお待ちいただけますと幸いです！
今後も進化し続ける Saibius でありたいと思います。
ご関心をお寄せいただきありがとうございます。
良い一日をお過ごしください :)
こんにちは。
よい夜をお過ごしでしょうか。
ご指摘いただいた Android の Termux 環境については、公式なテストはまだ実施していませんが、今後の追加開発およびテスト予定に含まれています。
テストが完了し次第、できるだけ早く返信いたします :b
また、Copyparty や Croc のような便利なツールをご紹介いただきありがとうございます。こうしたツールについても詳しく調べてみたいと思います...
これからも成長していく Saibius でありたいと思います。
ご関心をお寄せいただきありがとうございます。
よい一日をお過ごしください :)
社内でのウェブ文書共有には、Python内蔵のウェブサーバーを使っています。
こんにちは。
よい午後をお過ごしでしょうか。
PythonのWebサーバーも本当に良いツールだと思います！
実は私たちもPythonの組み込みWebサーバーを使っていたのですが、こちらではWebドキュメントだけでなく、AI学習データやチェックポイントファイル（
.safetensors、.ckptなど）も扱っているため、数百GB〜数TB級のファイルでは接続が途中で切れたり、不安定になったりすることがよくありました。その代替としてNASも運用していますが、大容量ファイルの場合は、やはりアップロード > サーバー > ダウンロードよりも、ファイルが置かれているデバイスから直接送るほうが速いため作ったプログラムなので、結局は環境に合ったツールがいちばん良いのだと思います。
よい一日をお過ごしください :)
その用途なら良い選択ですね。暗号化機能はありますか？ 保存時は暗号化し、共有時には復号化する機能はあるのでしょうか？
こんにちは！ ご質問ありがとうございます。
現行バージョンでは、ご指摘の「暗号化機能」および「保存 / 暗号化機能」には対応していません。
実は開発初期に検討していましたが、「内部ネットワークで一時的にファイル転送」することに特化したツールである点、
大容量データ共有環境では暗号化のオーバーヘッドが転送速度に影響する点から、
残念ながら対象外とすることになりました。
当方では、暗号化が必要な場合は主にNASの暗号化保存機能を活用しています。
セイビウスにご関心をお寄せいただき、ありがとうございます。
よい一日をお過ごしください :)
[更新] 無料キー配布終了のお知らせ
たくさんのご関心をお寄せいただき、ありがとうございます！
2026年01月22日 13:10時点で、すべての無料キーの配布が終了しました。
[配布終了したキー]
初回無料キー(R1)、後日配布された U1、C1
皆さまのご声援を力に、今後もさらに発展していく
セイビウスであり続けます。
ありがとうございます。
[更新] 多くのご関心をお寄せいただき、ありがとうございます!
初期の無料キーはすぐに配布終了となり、一部の方は引き換えエラーを経験されました。
問題を修正し、追加で20個提供します。
https://saibius.com/redeem?key=SAIBIUS-2026-U1
https://saibius.com/redeem?key=SAIBIUS-2026-C1
以前のコードでエラーが発生した方は、新しいコードでもう一度お試しください!
セリングポイントが弱く感じられるので、フィードバックをお送りします。Web UI の必要性があまりうまく説得されていないように思います。ターミナルが主力インターフェースなのであれば、コマンドで受け取ったファイルを
firefox <html_file>やcat <text_file>のように、そのファイルを開くアプリケーションをすぐに実行できるのではないでしょうか。バイナリサイズもさらに小さくできそうです。もし GUI フレンドリーにするのであれば、各プラットフォームの explorer や finder の右クリックメニューにショートカットを追加してもよいと思います。もし Web UI まで取り除けるのであれば、https://github.com/schollz/croc と比較されることになりそうです。私がメインで使っているツールなのですが、別途ランタイム不要でローカル転送も十分高速ですし、relay p2p によるリモート転送でも e2e encryption をサポートしていて、転送再開（resume）にも対応しています。ご丁寧なフィードバックをありがとうございます！
GUIショートカットの部分は追加したほうがよさそうです。
まず、ご指摘いただいた点について回答いたします。
WebUIの必要性
ターミナルが主なインターフェースではありますが、このプログラムはマーケターやデザイナーなど、サーバー環境やターミナル環境に慣れていないチームメンバーにも共有できるよう設計しており、そのため WebUI を差別化要素として打ち出そうとしています。
ファイル実行に関する部分
このプログラムは基本的に「一時ファイル共有サーバー」に焦点を当てているため、そのファイルを開くアプリケーションを直接実行することはしていません。私たちが普段使う拡張子の中には、異なるプログラムが同じ拡張子を共有している場合があるためです。
CROCとの違い
ご指摘のツールとの最も大きな違いとしては、Zero-Copy のサポートと動的バッファ最適化（ファイルに応じたバッファ可変）あたりになるかと思います。このツールでも基本的に IDM（または FDM）をサポートするために HttpRange を適用していました。
ご提案いただいたショートカット機能はとても良いアイデアだと思います。今後のアップデートで反映できるよう勉強してみます。
良い一日を！ :)
--fileフラグのないパラメータは、共有するリソースとして扱わないのでしょうか？ご丁寧なフィードバックをありがとうございます！
--fileフラグについては、こちらでも認識しています。初期バージョンでは、フラグがなくてもファイル共有が可能でした。
ただ、ベータテストの過程で、「ファイルが即座に共有される特性上、ユーザーが意図せずコピー＆ペーストによってクリップボード内の誤ったパスを共有してしまう可能性がある」という懸念が出たため、入力手順をもう一段設け、
現時点では明示的な
--fileフラグを要求するように変更されました。おっしゃる通り、利便性の面ではフラグなしでも動作するほうが良い可能性があるという点には、私たちも共感しています。セキュリティと利便性のバランスをどう取るか、引き続きテスト中です。
ご提案いただいた
--fileフラグ省略機能は、とても良いアイデアだと思います。良いアイデアをありがとうございます :)
良い一日をお過ごしください :)
サーバー利用者の想定が開発者なのか一般ユーザーなのか、よく分かりませんね。開発者向けなら、誤ったパスの貼り付け防止は煩わしいですし、一般ユーザー向けなら、コマンドプロンプトを開いて
--fileフラグを入力しなければならない不便さがあります。--fileフラグがないと、エクスプローラーからフォルダーを実行ファイルにドラッグ＆ドロップして即座に共有できる方法を捨てることになります。そうなると利便性のためにシステムメニューへの項目追加を検討することになるでしょうが、そのショートカットメニューを月に何回使うのでしょうか？追加のフィードバックをありがとうございます。
おっしゃるとおり、開発者の使いやすさと一般ユーザーの利便性のどちらも見逃せない重要な点だと考えています。
ただし、現時点では既存ユーザーの安定したワークフローを維持することを優先すべきだと判断しています。
ご提案いただいた「フラグ省略」や「インターフェース改善」などのアイデアは、今後の大規模なアップデートのタイミングに合わせて、下位互換性を損なわない範囲で慎重に検討していきます。
関心をお寄せいただきありがとうございます。
ご指摘いただいた CROC は優れたツールですが、受信側のデバイスにも CROC をインストールする必要があり、コマンドラインを使える必要がある一方で、私たちのツールは Wget/Curl サポートに加えて webUI も提供しているため、非開発者のチームメンバーもブラウザだけで簡単に使えていました。
ショートカットのアイデアも本当にありがとうございます！ こうした機能が実装可能だということ自体、失念していました。
良い一日を :)