ローカルコードからデプロイ
コードが GitHub にない場合、または変更をすぐに試したい場合は、lizard up を使って現在のディレクトリを直接アップロードできます。作業ツリーを tarball としてパッケージ化し、ビルドノードに送信してデプロイします。各スタックに必要なコマンドについては、React、Vue、Astro、SvelteKit、Hugo、Docusaurus、VitePress、FastAPI、Streamlit のガイドを参照してください。
現在のディレクトリをデプロイ
lizard up- 現在のディレクトリを tarball としてアップロードします。git リポジトリ内では
.gitignoreを尊重します(--no-gitignoreで無効化)。git の外では、決まったビルド用・依存関係用フォルダー(node_modules、.git、dist、.next、build、__pycache__、.venv、venv、.cache、coverage、.turbo、.vercel)と、.DS_Store、*.pyc、*.pyo、*.logだけをスキップするため、.envファイルはアップロードされます。先にgit initを実行するか、シークレットを移動してください。 sourceType=uploadを強制します。- SSE 経由でビルドログをストリーミングし、完了時にライブ URL を表示します。
ディレクトリがまだプロジェクトにリンクされていない場合、up は最初に init を実行します。TTY では対話的に動作しますが、非 TTY(CI)では空のプロジェクトを暗黙的に作成することはありません。代わりにエラーになり、lizard init --name <project> を実行するよう求めます(または up に --project <name> を渡します)。これは、タイプミスによって空のプロジェクトが作成されるのを防ぐためです。
よく使うフラグ
| フラグ | 目的 |
|---|---|
-s, --service <name> | 既存のサービスを対象にする |
--build-command <cmd> | build コマンドを上書きする |
--start-command <cmd> | start コマンドを上書きする |
--pre-deploy-command <cmd> | すべてのコンテナの起動時に、start コマンドの前に実行する。--start-command が必要(ビルド設定 を参照) |
--port <number> | コンテナポート(0 = worker mode) |
--region <code> | 新しいサービスのリージョン(既存のサービスでは無視される) |
-d, --detach | デプロイを開始して、ログをストリーミングせずに終了する |
-c, --ci | CI 向けの出力 |
--no-gitignore | .gitignore を無視してすべてをアップロードする |
lizard up --service api --start-command "node server.js" --port 8080build/start コマンドの設定
--build-command または --start-command を渡すと、その値がサービスに保存され、dockerfilePath が設定されていない限り、サービスは synthesized Dockerfile パスに切り替わります。このパスでは、Procfile と package.json scripts.start は読み取られません。start コマンドを明示的に設定してください。詳しくは ビルド Pipeline を参照してください。特に影響を受けやすいのは Python です。Django, Flask and FastAPI では、それぞれ異なる gunicorn または uvicorn の行が必要です。
アップロードサービスを再デプロイする
lizard up は再アップロードして再ビルドします。再アップロードせずに、現在の変数で前回のアップロードを再ビルドするには:
lizard redeploy --service apiヘッドレス / CI
非対話フローでは、デプロイ前に明示的にプロジェクトをリンクしてください:
export LIZARD_TOKEN=liz_xxx # create one with: lizard keys create <name>
lizard init --name my-project
lizard up --ci --service api代わりに GitHub を使うべき場合
アップロードは、すばやい反復やリモートがない状況に最適です。長期的に運用するものについては、プッシュ時に自動で再デプロイされ、クリーンなデプロイ履歴も得られるため、GitHub source を使うことをおすすめします。
関連項目
lizard up:完全なコマンドリファレンス。- ビルド Pipeline:スタックがどのように検出され、ビルドされるか。
更新日