個人的に利用してきた fly.io から、新たに Sprites というサービスが出ました。 「ファイルを保持したまま使える」「起動も数秒以内」という触れ込みで、簡易的なwebサーバーにも使えるそうです。 しかし、まだ出たばかりで日本語はおろか英語の文献もあまりありません。 そのため、今回は実際にSpritesを使って、サーバーを建てたり、起動の挙動を見てみようと思います。
Spritesとは？
Spritesは fly.io が新しく出した実行環境で、ざっくり理解すると 状態を保持したまま使える、起動の早いサンドボックス というようなサービスです。 AWSのLambdaやGCPのCloud Functionsと異なるのは、ファイルシステムがそのまま保持されること、つまり、インストールしたツールだけでなくアプリが変更を加えたファイルがそのまま 残り続けるという点だ。 しかも、使っていないときには自動的に休止し、必要になったらすぐ起きる、という挙動をする。
fly.ioがすでに出しているVMよりも重くなく、しかしステートレスなサーバーレス環境より常駐できるような、ちょうど中間を狙ったようなプロダクトという印象です。
特に高速起動は強みとして挙げられているので、これが実際にどれくらいの速さなのか、確かめてみました。
1. Spritesのインストール・起動
筆者環境：
- Ubuntu 22 LTS on WSL2
Quick Startに従いますが、一部エラーになるため変えています。
インストール
$ $url -fsSL https://sprites.dev/install.sh | shだとsh: 2: set: Illegal option -o pipefailとエラーになったため、bashにします。
$ curl -fsSL https://sprites.dev/install.sh | bashログイン
$ sprite loginSpriteの作成
コンテナを作成する感じです。
$ sprite create coldstart-test
> ✓ Created coldstart-test sprite in 3.9s
sprite@sprite:~$こんな形でsprite内のシェルが開かれます。
2. Sprite内でのHTTPエンドポイント作成
Spriteでは、8080ポートをリッスンしてくれます。 それに合わせてNginxを設定します。
$ sudo apt update
$ sudo apt upgradeいつものをしましたが、何も更新されませんでした。最新版で入っているようですね。
Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
Nginxのインストールと設定
$ sudo apt install nginx
$ sudo service nginx status
> * nginx is not runningsystemctlは入っていないようです。ここではserviceを使っていきます。
インストールはできました。まだ起動していません。
（参考）
$ systemctl
> bash: systemctl: command not found続いて、Nginxの設定を修正します。
$ sudo nano /etc/nginx/sites-available/default設定項目のうち、ポート番号を80から8080に変えておきます。
# Default server configuration
#
server {
listen 8080 default_server;
listen [::]:8080 default_server;確認
$ sudo nginx -t
> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /etc/nginx/nginx.conf test is successfulNginxの起動
serviceを利用して起動します。
$ sudo service nginx start
> * Starting nginx nginx
$ sudo service nginx status
> * nginx is runninglocalで確認
$ curl localhost:8080
> <!DOCTYPE html>
> <html>
> <head>
> <title>Welcome to nginx!</title>
...(以下略)3. インターネットへの公開
ctrl+Dを押して、spriteのコンソールから抜けます。
マシン起動の確認
$ sprite ls
┌──────────────┬───────┬───────┐
│ NAME │STATUS │CREATED│
├──────────────┼───────┼───────┤
│coldstart-test│running│21m ago│
└──────────────┴───────┴───────┘
Total: 1 sprite(s)マシンは起動しているようです。このマシンをインターネットへ公開しましょう。
URLの取得
$ sprite url
> URL: https://<sprite created url>.sprites.app
> Auth: spriteまだこのURLにアクセスしても認証ヘッダーが無ければ通りません。 このURLを公開します。
$ sprite url update --auth public
> Auth: public
> URL: https://<sprite created url>.sprites.appURLは変わりませんが、これでhttps化されたURLに全世界からアクセスできます。 ブラウザに張り付けてみましょう。
これでNginx初期画面が表示できました。
ちなみに、この時の応答時間(ホット)はおよぼ600msでした。
アメリカにあるサーバーと通信しているようなので、このくらいになるのかもしれません。 何回か試しましたが、500ms～700msの間を前後するような結果でした
4. コールドスタート時の速度計測
コールドスタートをさせるために、Spriteが起動したときに自動で立ち上がるよう Servicesを使ってnginxを立ち上げます。
sprite-env servicesでの起動
とりあえず先ほど起動したnginxを停止してsprite-env servicesで登録しましょう。
sprite内に入る
$ sprite consoleserviceは止めておきます。
$ sudo service nginx stop/usr/sbin/nginx -g 'daemon off;'をサービスに登録します。
$ sprite-env services create nginx \
--cmd /usr/sbin/nginx \
--args "-g,daemon off;" \
--http-port 8080
> {"type":"started","timestamp":1769338811598}
> {"type":"stderr","data":"2026/01/25 11:00:11 [warn] 332#332: the \"user\" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1\n","timestamp":1769338811604}
> {"type":"complete","log_files":{"combined":"/.sprite/logs/services/nginx.log","stderr":"/.sprite/logs/services/nginx.log","stdout":"/.sprite/logs/services/nginx.log"},"timestamp":1769338816597}この状態でも、先ほどのURLをたたくとnginxが起動できることを確認します。 起動の仕方を変えられました。
コールドスタートでの計測
sprite環境を抜けて、サーバーがrunnningでなくなるまで待ちましょう。
$ sprite ls
> Sprites in organization <org namge>
┌──────────────┬──────┬───────┐
│ NAME │STATUS│CREATED│
├──────────────┼──────┼───────┤
│coldstart-test│warm │ 3h ago│
└──────────────┴──────┴───────┘
この状態で、先ほどのURLを叩きます。
5回試しましたが、Waiting for server responseの値はそれぞれ、4.2s, 3.4s, 2.0s, 3.9s, 1.8sでした。
少し分散はは大きいですが、少なくとも2秒以上はかかるといったところでしょうか？
結果
| Server Status | Waiting Time |
|---|---|
| running (hot) | 600 ms |
| warn (cold) | 2 ~ 4 s |
サーバーが米国にある影響もあるのか、 正直なところ Web サーバーとして使うには 起動までの待ち時間はやや長く感じました。
特に、しばらくアクセスがない状態からの起動では 最大で4 秒近く待つことになるため、 ユーザーが直接触る用途だと少し限定されることになるかもしれません。
一方で、頻繁にアクセスされるわけではないツールや検証用途など、 起動が遅くても問題にならないケースであれば、 割り切って使う分にはアリだと思いました。 特にアクセスがほとんどない + 24h動かすにはサーバー代がもったいないケースではよさそうですね。DBも中に入れられそうです。
用途を選びつつ、使えそうな場面では活用していきたいと思いました。
補足
検証環境
今回の検証は、以前スターレンタルサーバーでPython(Flask)をデプロイしてみたで速度計測を行った環境と同じ、 1G有線接続の光回線で行いました。
sprite-env servicesコマンド
sprite-env servicesコマンドの使い方はあまりドキュメントにも載っていませんでした。執筆時点でのcli内容は次の通りでした。
$ sprite-env services --help
> sprite-env services - Manage long-running services
>
> USAGE:
> sprite-env services <subcommand> [options]
>
> SUBCOMMANDS:
> list List all services and their states
> get <name> Get a specific service's state
> create <name> [opts] Create a new service
> delete <name> Delete a service
> start <name> Start a stopped service
> stop <name> Stop a running service (sends TERM signal)
> restart <name> Restart a service (stop + start)
> signal <name> <signal> Send a signal to a service (e.g., TERM, HUP, KILL)
>
> CREATE OPTIONS:
> --cmd <command> Command to run (required)
> --args <arg1,arg2,...> Comma-separated arguments
> --env <KEY=val,...> Comma-separated environment variables
> --dir <path> Working directory
> --needs <svc1,svc2> Comma-separated service dependencies
> --http-port <port> HTTP port for proxy routing (only one service can have this)
> --duration <time> How long to stream logs (default: 5s, e.g., 10s, 1m)
> --no-stream Don't stream logs after creation
>
> HTTP PORT:
> When a service is created with --http-port, the Sprite proxy will:
> - Route incoming HTTP requests to that port instead of the default 8080
> - Auto-start the service if it's not running when a request arrives
> - Only one service can have an HTTP port configured at a time
>
> EXAMPLES:
> sprite-env services list
> sprite-env services get myapp
> sprite-env services create myapp --cmd /usr/bin/node --args server.js --http-port 3000
> sprite-env services create redis --cmd redis-server --duration 10s
> sprite-env services delete myapp
> sprite-env services signal myapp TERM
