LocalCloud MCP server
2026년 11월 5일 커밋Model Context Protocol 브릿지를 사용하여 AI agent가 Google Cloud 애플리케이션을 빌드, 테스트 및 디버깅할 수 있는 로컬 클라우드 환경을 제공합니다.
다른 이름 LocalGCloud/localcloud-cli, localcloud-cli
- 스타
- 1
- Tools
- —
- 다운로드, 30일
- —
- 최신 버전
- 0.1.12
- 마지막 커밋
- 2026년 11월 5일
- 라이선스
- —
LocalCloud MCP란?
LocalCloud은(는) MCP server입니다. Model Context Protocol 브릿지를 사용하여 AI agent가 Google Cloud 애플리케이션을 빌드, 테스트 및 디버깅할 수 있는 로컬 클라우드 환경을 제공합니다.
프로젝트 README에서 생성된 요약
LocalCloud MCP server 정보
LocalCloud는 개발자와 AI 코딩 agent가 서비스 비용 부담 없이 Google Cloud 애플리케이션을 빌드, 테스트 및 디버깅할 수 있도록 설계된 로컬 클라우드 환경입니다. Model Context Protocol 브릿지를 사용하여 AI agent가 로컬 서비스와 직접 상호작용할 수 있으며, 이를 통해 agent가 자체 워크플로우 내에서 상태를 프로비저닝, 시딩, 검사 및 리셋할 수 있습니다. 이 환경은 Docker 컨테이너 내부에서 실행되며 단일 CLI 도구를 통해 다양한 서비스의 라이프사이클을 관리합니다.
사용자는 localcloud 또는 lc 명령줄 인터페이스를 사용하여 시스템과 상호작용합니다. 기존 애플리케이션 코드를 연결하려면 명령어를 실행하여 공식 Google 클라이언트 라이브러리를 로컬 루프백 엔드포인트로 리다이렉트하는 환경 변수를 내보내면 됩니다. 이 설정을 위해서는 Docker와 최소 4 GiB 이상의 가용 메모리가 필요합니다. 이 플랫폼은 BigQuery, Pub/Sub, Spanner, Cloud SQL, Cloud Storage를 포함한 27가지의 다양한 서비스를 지원하여, 로컬의 지속 가능한 인프라에서 실행되는 동안 애플리케이션 코드가 변경되지 않도록 보장합니다.
활용 사례
- 1자동화된 환경 프로비저닝AI agent가 코딩 루프의 일부로 로컬 Google Cloud 환경을 설정하고 관리할 수 있습니다.
- 2비용 없는 애플리케이션 테스트개발자는 Google Cloud 서비스 비용을 피하기 위해 복잡한 서비스 워크플로우를 로컬에서 실행할 수 있습니다.
- 3원활한 SDK 통합엔드포인트 인자를 수정할 필요 없이 코드에서 표준 Google 클라이언트 라이브러리를 사용할 수 있습니다.
프로젝트의 README를 바탕으로 작성되었습니다. 모든 활용 사례는 해당 내용의 인용문과 대조하여 확인합니다.
구성
BIGQUERY_EMULATOR_HOSTBIGTABLE_EMULATOR_HOSTCLOUDSDK_API_ENDPOINT_OVERRIDES_STORAGECLOUDSDK_CORE_PROJECTGOOGLE_BIGQUERY_CUSTOM_ENDPOINTGOOGLE_CLOUD_PROJECTGOOGLE_OAUTH_ACCESS_TOKENGOOGLE_PROJECTGOOGLE_STORAGE_CUSTOM_ENDPOINTLOCALCLOUD_RUN_IDENTITY_E2ENO_COLORSPANNER_EMULATOR_HOSTSTORAGE_EMULATOR_HOST
| 이름 | 설명 | 유형 |
|---|---|---|
| BIGQUERY_EMULATOR_HOST | — | |
| BIGTABLE_EMULATOR_HOST | — | |
| CLOUDSDK_API_ENDPOINT_OVERRIDES_STORAGE | — | |
| CLOUDSDK_CORE_PROJECT | — | |
| GOOGLE_BIGQUERY_CUSTOM_ENDPOINT | — | |
| GOOGLE_CLOUD_PROJECT | — | |
| GOOGLE_OAUTH_ACCESS_TOKEN | — | |
| GOOGLE_PROJECT | — | |
| GOOGLE_STORAGE_CUSTOM_ENDPOINT | — | |
| LOCALCLOUD_RUN_IDENTITY_E2E | — | |
| NO_COLOR | — | |
| SPANNER_EMULATOR_HOST | — | |
| STORAGE_EMULATOR_HOST | — |
자동 검사
2026년 11월 14일에 실행됨전체 보고서 →아직 인증되지 않았습니다. 서버는 80점 이상의 점수, 심각한 결함 없음, 그리고 검사에 충분한 데이터를 갖추어야 합니다. 검사 방식
- 소스 저장소 연결 및 접근 가능localgcloud/localcloud-cli is public and reachablegithub.com/localgcloud/localcloud-cli ↗통과
- 패키지가 이 저장소를 소스로 지정검사되지 않음
- 빌드 출처(Sigstore 증명)검사되지 않음
- 오픈 소스 라이선스 (OSI)No license결함 발견
- 최근 1년 내 커밋 또는 릴리스Last commit or release 2026-11-05github.com/localgcloud/localcloud-cli ↗통과
- OpenSSF Scorecard검사되지 않음
- 패키지 이름이 인기 패키지와 유사하지 않음검사되지 않음
- 패키지와 의존성에 심각한 보안 권고 없음검사되지 않음
- 모델에 대한 숨겨진 지침 없음0 tool descriptions and the README read; no override phrases, credential paths or hidden characters통과
- 파괴적인 도구에 라벨 표시됨검사되지 않음
- 원격 endpoint가 MCP 핸드셰이크에 응답검사되지 않음
README
GitHub에서 보기LocalCloud CLI
A free local cloud environment for developers and AI coding agents.
Build, test, and debug Google Cloud applications from your terminal or coding agent. MCP connects your agent to local services, SDK configuration, test data, readiness, and diagnostics.
Run local service workflows without Google Cloud service charges, start with one command, and create local projects for your experiments and test suites within your machine's capacity.
Website · MCP guide · Claude & Codex marketplace setup
Install · Quickstart · How it works · Services · Commands · AI agents & MCP · Troubleshooting
localcloud (aliased lc) is the official host CLI for LocalCloud. It manages the
container runtime lifecycle, multi-project context, SDK environment variables, persistent Docker volumes,
and the Model Context Protocol bridge — so your application code keeps calling the same Google Cloud client
libraries it already uses, just pointed at loopback.
$ lc doctor
╭── LocalCloud v0.1.14 ───────────────────────────────────────────────────────────────────────╮
│ │ Top commands │
│ Checking LocalCloud setup │ localcloud (or lc) status | start | stop | restart │
│ │ eval $(lc env) Exports env vars that redirect cloud se…│
│ ╭────╮ │────────────────────────────────────────────────────────────────│
│ ╭──╯ ╰──╮ │ Context │
│ ╭─╯ ╰─╮ │ Data Volume: localcloud-data Project: local-gcp-project│
│ ╭╯ ╰╮ │ User: local-developer │
│ ╰──────────────╯ │ Config: built-in defaults (overridable by ./localcloud.yaml) │
│ │ │
├────────────────────────────┴────────────────────────────────────────────────────────────────┤
│ Supported Services (● 22 enabled · ○ 5 disabled) │
│ ● Storage ● Pub/Sub ○ Firestore ● Bigtable ● Spanner ● BigQuery │
│ ● Cloud SQL ● AlloyDB ● Memorystore ● Dataproc ● Tasks ● Scheduler │
│ ● Functions ○ Cloud Run ○ Compute ○ GKE ● Workflows ○ Vertex AI │
│ ● Sheets ● KMS ● Secrets ● IAM ● Logging ● Monitoring │
│ ● Resource Mgr ● Service Usage ● Billing │
╰─────────────────────────────────────────────────────────────────────────────────────────────╯
Tip: Run localcloud guide for AI agent workflows, or lc for the fast alias.
Docker 29.8.1 (/opt/homebrew/bin/docker) · Colima 0.10.1 (VZ, Rosetta on)
Image agentcloud/localcloud:lite (ID: 66d2113a69fb)
Ports 5380-5406 (in use by localcloud)
[OK] LocalCloud is ready to start 0.5s
Why LocalCloud
- 27 services, one container. Storage, Pub/Sub, BigQuery, Spanner, Bigtable, Firestore, IAM, KMS, Dataproc, Cloud Run and more come up together — not as a dozen emulators you wire up by hand.
- Your SDK code doesn't change.
eval "$(lc env)"exports the emulator variables the official Google client libraries already look for. Same calls, same objects, loopback endpoints. - Isolated, durable environments. A named Docker volume is the runtime's identity. Run a scratch environment for CI beside your everyday one, and keep data across restarts.
- Built for humans and automation. Every command renders a readable terminal summary, and the same
result as complete JSON with
--verbose.--dry-runpreviews mutations;--debugprints the equivalentdocker run. - Agent-native. A first-class MCP bridge lets AI coding agents provision, seed, inspect, and reset real GCP-shaped state as part of their own loop — not a UI a person has to click through.
- Zero live-cloud footprint. The CLI validates that every generated endpoint is loopback and refuses to
emit a real
googleapis.comaddress. There is no silent fallback to production.
How it compares
| LocalCloud | gcloud beta emulators |
Testcontainers | Real GCP dev project | |
|---|---|---|---|---|
| Services | 27 | ~5 (Bigtable, Datastore/Firestore, Pub/Sub, Spanner) | Wraps the same emulators | All |
| Setup | One CLI command | One process per service | Written in test code | Project, billing, IAM |
| SDK wiring | eval "$(lc env)" |
Per-emulator, manual | Per-container, in code | ADC + real credentials |
| Web console | Built in | — | — | Yes |
| Terraform / OpenTofu | lc env --format terraform |
— | — | Yes |
| Agent control (MCP) | Built in | — | — | — |
| Data persistence | Docker volume, survives restarts | Process lifetime | Test lifetime | Durable |
| Cost / credentials | None | None | None | Billed, real keys |
Breadth is service availability — a callable, service-level integration. Operation-level parity is service-specific and recorded per service in the LocalCloud compatibility matrix.
Install
Prerequisites
Docker Desktop, Colima, OrbStack, Rancher Desktop, or Docker Engine, installed and running. LocalCloud needs at least 4 GiB of memory available to the container for stable operation.
No Docker yet? On macOS with Homebrew, lc doctor --fix (or lc start in a terminal) offers to install
Colima, a free, lightweight Docker engine, and starts it with 4 CPUs
and 8 GiB of memory.
On Apple Silicon, run the Docker VM on VZ with Rosetta rather than QEMU: it is faster, and QEMU has
known issues with LocalCloud (the BigQuery emulator can fail under it). lc doctor reports the Docker
app, its VM type and Rosetta, and lc doctor --fix offers to switch Colima or Rancher Desktop.
macOS and Linux
curl -fsSL https://local.cloud/install.sh | sh
The installer adds localcloud and the shorter lc alias when available.
Homebrew
brew install LocalGCloud/tap/localcloud
brew upgrade localcloud # upgrade
brew uninstall localcloud # remove
Upgrading
Update the CLI to the latest release:
lc update
lc update detects how LocalCloud was installed (script installer or Homebrew) and upgrades the CLI in place. For Homebrew, brew upgrade localcloud also works.
Standalone binaries
Signed release archives with Sigstore verification bundles are published for:
| Platform | Architectures | Minimum |
|---|---|---|
| macOS | Apple Silicon | macOS 13+ |
| Linux | x86_64, aarch64 |
glibc 2.35+ (Ubuntu 22.04+) |
Intel Macs are not supported: 0.1.11 was the last release with an Intel macOS archive.
Windows users can run the container directly — see the Docker setup instructions.
Verify
$ lc --version
localcloud 0.1.14 (commit c2bed60e4464, released 2026-11-03)
Release builds embed their exact source commit and release date, so a binary can always be traced back.
Quickstart
Five minutes from nothing to a working Cloud Storage bucket.
1. Check your machine
lc doctor
Confirms Docker connectivity, reports the Docker app and its VM setup, and shows the resolved LocalCloud
context. Continue when the last line starts with [OK]. It creates no LocalCloud state, so it is always safe
to run first.
If it lists Setup findings, lc doctor --fix offers to fix them, asking before each change.
2. Start the runtime
lc start
Config built-in defaults (overridable by ./localcloud.yaml)
Data volume localcloud-data
Origin managed
Project local-gcp-project
User local-developer
Image agentcloud/localcloud:lite
Image status Available locally
URL http://127.0.0.1:5380
Ports 5380-5406
Services alloydb, bigquery, bigtable, cloudbilling, cloudfunctions, cloudiam,
cloudresourcemanager, cloudscheduler, cloudsql, cloudtasks, dataproc, gcs,
kms, logging, memorystore, monitoring, pubsub, secretmanager, serviceusage,
sheets, spanner, workflows
[OK] LocalCloud is ready 8.4s
start checks the registry for a newer image by default (--no-pull to skip), publishes the canonical
ports on all host interfaces, waits for service readiness, and tails logs for five seconds.
A service that reports a permanent failure doesn't fail the start. The command succeeds and warns
that the service is not available, giving the runtime's reason.
Use lc start --local-only to bind published ports to 127.0.0.1 instead.
Pass --local-only on subsequent start, restart, and reset commands to keep that binding.
Running start again on a live runtime is safe.
3. Configure your shell
eval "$(lc env)"
This exports the variables the official Google client libraries already read:
export STORAGE_EMULATOR_HOST="http://127.0.0.1:5382"
export BIGQUERY_EMULATOR_HOST="http://127.0.0.1:5388"
export SPANNER_EMULATOR_HOST="127.0.0.1:5386"
export BIGTABLE_EMULATOR_HOST="127.0.0.1:5385"
export GOOGLE_CLOUD_PROJECT="local-gcp-project"
export CLOUDSDK_CORE_PROJECT="local-gcp-project"
export CLOUDSDK_API_ENDPOINT_OVERRIDES_STORAGE="http://127.0.0.1:5382/"
# …one entry per enabled service, plus gcloud endpoint overrides and a local access token
4. Call it from your code
No LocalCloud-specific client. No endpoint arguments. The environment does the work.
Python
from google.cloud import storage
client = storage.Client()
bucket = client.create_bucket("my-bucket")
bucket.blob("hello.txt").upload_from_string(
"Hello from LocalCloud!"
)
Node.js / TypeScript
import { Storage } from "@google-cloud/storage";
const storage = new Storage();
const [bucket] = await storage.createBucket("my-bucket");
await bucket.file("hello.txt")
.save("Hello from LocalCloud!");
Go
ctx := context.Background()
client, _ := storage.NewClient(ctx)
defer client.Close()
bucket := client.Bucket("my-bucket")
_ = bucket.Create(ctx, "local-gcp-project", nil)
gcloud CLI
gcloud storage buckets create gs://my-bucket
gcloud storage ls
5. Look around, then stop
lc console # open the web console for the selected project
lc status # runtime health, endpoints, and ownership
lc logs # recent runtime logs
lc restart # recreate runtime with current local image (--pull to check registry)
lc stop # stop the container; the data volume is untouched
Your data survives stop and restart. lc start brings it back exactly as it was.
Tip for AI coding agents: Skip manual shell setup! Head to AI agents & MCP to configure Cursor, Claude Code, or Windsurf in one command (
lc mcp install).
How it works
your code ──► google-cloud-* SDK ──► 127.0.0.1:5380-5406 ─────────┐
terraform ──► GOOGLE_*_CUSTOM_ENDPOINT ───────────────────────────┤
AI agent ──► lc mcp (stdio) / :5380/mcp (HTTP) ──────────────────┤
│
┌─────────────────────────────────────────────┘
┌───────────▼─────────────────────────────────────────────┐
│ Docker container · agentcloud/localcloud │
│ │
│ :5380 gateway · console · admin API · MCP · facades │
│ :5382 Cloud Storage :5386-87 Spanner │
│ :5383 Pub/Sub :5388-89 BigQuery │
│ :5384 Firestore :5390 Memorystore │
│ :5385 Bigtable :5391 PostgreSQL │
└───────────────────┬─────────────────────────────────────┘
│
Docker volume: localcloud-data
mounted at : /var/lib/localcloud
The CLI never becomes a proxy — it configures and supervises. Once lc start returns, your SDK talks to
the container directly.
Three identities, deliberately separate
This is the one concept worth internalizing, because every flag follows from it:
| Axis | Flag | What it selects | Scope |
|---|---|---|---|
| Data volume | --data-volume |
The durable runtime identity — a named Docker volume mounted at /var/lib/localcloud. Two volumes are two independent LocalClouds. |
Docker |
| Project | --project-id |
A logical Google Cloud project inside one runtime. Many projects share a volume. start and MCP startup create a missing one. |
Request |
| User | --user |
The attributed caller sent to LocalCloud services, normalized to <name>@localcloud.invalid where a principal is required. |
Request |
Project and user are request context: switching them is instant and never touches Docker. Defaults are
localcloud-data, local-gcp-project, and local-developer. The MCP bridge instead gives each git
repository its own project, named after the repository, unless --project-id or the repository's
localcloud.yaml names one.
Ports
New runtimes prefer the canonical range 5380–5405 (plus DNS 5410/udp). With Cloud SQL MySQL
enabled, the set also includes 5406, which LocalCloud's MySQL companion container publishes. If that
complete set is unavailable, the CLI proposes one contiguous alternative from 5508–5539, then
5821–5840, then 5322–5342, and asks before creating the container. Such a runtime publishes only
the ports its enabled services use, so four can run beside the canonical one. To pick the host ports
yourself, set host.port_range: 6000-6099 or pass --port-range 6000-6099. The CLI never scans the
operating system's general ephemeral range, and lc env always emits the ports actually in use.
Services
27 Google Cloud–compatible services, 22 enabled by default:
| Group | Services |
|---|---|
| Storage & databases | Cloud Storage, Firestore, Bigtable, Spanner, BigQuery, AlloyDB, Cloud SQL, Memorystore |
| Messaging & orchestration | Pub/Sub, Cloud Tasks, Cloud Scheduler, Cloud Workflows |
| Compute & serverless | Cloud Functions, Cloud Run, Compute Engine, GKE, Dataproc |
| Security & identity | Cloud IAM, Secret Manager, Cloud KMS |
| Management & billing | Resource Manager, Service Usage, Cloud Billing |
| Observability | Cloud Logging, Cloud Monitoring |
| AI & productivity | Vertex AI, Google Sheets |
Use the ID with --services or services.enabled in localcloud.yaml.
| ID | Google Cloud service | Default |
|---|---|---|
gcs |
Cloud Storage | ● on |
pubsub |
Pub/Sub | ● on |
firestore |
Firestore | ○ off |
bigtable |
Bigtable | ● on |
spanner |
Spanner | ● on |
bigquery |
BigQuery | ● on |
sheets |
Google Sheets | ● on |
secretmanager |
Secret Manager | ● on |
cloudtasks |
Cloud Tasks | ● on |
cloudscheduler |
Cloud Scheduler | ● on |
cloudfunctions |
Cloud Functions (2nd Gen) | ● on |
alloydb |
AlloyDB | ● on |
dataproc |
Dataproc | ● on |
cloudiam |
Cloud IAM | ● on |
cloudresourcemanager |
Cloud Resource Manager | ● on |
serviceusage |
Service Usage | ● on |
cloudbilling |
Cloud Billing | ● on |
logging |
Cloud Logging | ● on |
monitoring |
Cloud Monitoring | ● on |
gke |
GKE | ○ off |
compute |
Compute Engine | ○ off |
cloudrun |
Cloud Run | ○ off |
memorystore |
Memorystore (Redis/Valkey) | ● on |
workflows |
Cloud Workflows | ● on |
vertexai |
Vertex AI | ○ off |
kms |
Cloud KMS | ● on |
cloudsql |
Cloud SQL | ● on |
● on services start automatically
when services.enabled is unset; ○ off services are available but must be selected explicitly.
Select an explicit set at start time, or reset to the built-in default:
lc start --services gcs,pubsub,bigquery,firestore
lc start --services default
Services you enable or disable in the Console are saved on the data volume and come back on the next
start. --services outranks them for that start without clearing them, and start prints a
Service sources line naming where each enabled service came from. See
Which services run.
Lite and full images. lc start runs the lite image (agentcloud/localcloud:lite) by default. It has
every service above, but BigQuery's lite edition (no BigQuery ML, JavaScript UDFs, or EXTERNAL_QUERY on
Cloud SQL; Spanner's still works), and GKE creates metadata-only clusters. --full runs the full image
(:latest, or <version> instead of <version>-lite); the runtime keeps it on later starts and restarts
until --lite.
lc start --full
Staying current. A runtime keeps the image it was started with. A floating tag like lite is
refreshed by --pull. A version tag like agentcloud/localcloud:0.1.8-lite never moves by itself,
so start and restart look for a newer version on the same channel (lite or full) and, in a terminal,
ask before switching:
A newer LocalCloud image is available for this runtime.
Current agentcloud/localcloud:0.1.8-lite (the image data volume 'localcloud-data' last ran)
Offered agentcloud/localcloud:0.1.11-lite (Docker Hub; will be pulled, 373.1 MB)
The runtime is recreated on the new image and its data volume is migrated forward, so going back may not be possible.
Use 0.1.11-lite now? [y/N]
The check reads Docker Hub's tag list at most once every 6 hours. When Docker Hub can't be reached,
it offers newer images already on your machine instead. A "no" is remembered for that data volume
until a newer version appears. Scripts and --verbose runs never switch: they get an Image update
line instead. An explicit --pull switches without asking. Set LOCALCLOUD_IMAGE_UPDATE_CHECK=false
to turn the check off. See Which image runs.
Commands
lc and localcloud are interchangeable in every example.
| Command | Purpose |
|---|---|
lc update |
Update the CLI through its script installer or Homebrew |
lc doctor |
Inspect Docker access, VM engine, and host setup; --fix interactively resolves issues |
lc start |
Start the runtime; supports --services, --local-only, --tls, --no-ui, and creating the project named by --project-id |
lc status |
Show runtime health, ownership, endpoints, and Docker details |
lc env |
Generate SDK, Terraform, or Docker Compose configuration; --identity starts a local identity session |
lc console |
Open the web console for the selected project and user |
lc logs |
Print recent runtime logs |
lc restart |
Recreate the container with the local image (default: --no-pull); --pull checks the registry and moves a pinned version to the newest |
lc reset |
Reset the selected project (--all-projects prints manual recreate steps) |
lc stop |
Stop the runtime without deleting persistent data |
lc cleanup |
Remove malformed Docker resources, stale runtime state, and legacy files |
lc guide |
Print authoritative coding-agent guidance |
lc mcp |
Run the stdio MCP bridge; lc mcp install configures AI coding agents |
Run lc COMMAND --help for command-specific flags and the valid --fields paths.
Output modes
Every command speaks to a person and to a script from the same result:
| Flag | Effect |
|---|---|
| (none) | Concise terminal summary, with spinners and elapsed time in an interactive shell |
--verbose |
The complete structured result as JSON on stdout |
--fields PATH[,PATH…] |
Append specific JSON paths to the concise summary |
--dry-run |
Validate and print every planned Docker and LocalCloud mutation, changing nothing |
--debug |
Diagnostics on stderr, including a copyable equivalent docker run command |
lc status --verbose | jq '.container.url'
lc start --fields mcp.direct_url,container.name
lc start --dry-run # preview before mutating anything
NO_COLOR=1 lc doctor # symbols still carry status without color
Service selection is marked with ● (on) and ○ (off) as well as color, so it stays legible under
NO_COLOR or a dumb terminal.
Exit codes
| Code | Meaning |
|---|---|
0 |
Success |
1 |
Completed with failures (for example cleanup partial), or an unexpected internal error |
2 |
LocalCloud error — invalid input, Docker problem, or a failed operation. Rendered as Error [code] message |
130 |
Command interrupted with Ctrl-C |
LocalCloud MCP 질문
LocalCloud는 기존 Google Cloud SDK와 어떻게 연동되나요?
환경 변수를 사용하여 공식 Google 클라이언트 라이브러리를 로컬 루프백 엔드포인트로 리다이렉트하므로, 코드 수정이 전혀 필요 없습니다.
LocalCloud 사용 시 Google Cloud 서비스 비용이 발생하나요?
아니요, Google Cloud 서비스 비용을 발생시키지 않고 워크플로우를 실행하도록 설계된 무료 로컬 환경입니다.
LocalCloud 실행을 위한 하드웨어 요구 사항은 무엇인가요?
LocalCloud는 Docker 호환 런타임과 컨테이너를 위한 최소 4 GiB 이상의 가용 메모리가 필요합니다.
런타임을 중지한 후에도 데이터를 유지할 수 있나요?
네, 데이터는 중지 및 재시작 후에도 유지되는 이름이 지정된 Docker volume에 저장됩니다.