{"slug": "stacker-deploy-multi-container-docker-stacks-with-one-cli-command", "title": "Stacker – Deploy multi-container Docker stacks with one CLI command", "summary": "Stacker v0.3.0 is a platform that turns any project into a deployable Docker stack with a single CLI command, adding AI-assisted stacker.yml generation from GitHub repos, healthcheck inference, and remote Vault-backed secrets. The update enables users to run 'stacker init --from-github owner/repo --with-ai' to have an LLM (Ollama, OpenAI, or Anthropic) scan project files and generate context-aware configurations, with automatic fallback to template-based generation if the AI provider is unreachable.", "body_md": "Stacker is a platform for turning any project into a deployable Docker stack. Add a `stacker.yml`\n\nto your repo, and Stacker generates Dockerfiles, docker-compose definitions, reverse-proxy configs, and deploys locally or to cloud providers — optionally with AI assistance.\n\n**v0.3.0 highlights:** generate `stacker.yml`\n\nfrom any GitHub repo with `stacker init --from-github`\n\n, infra-service healthcheck inference, remote Vault-backed secrets for deployable service/app targets, paused or failed cloud/server installs retain discovered IP addresses, and cloud-provider firewalls can be managed without SSH.\n\n```\ncurl -fsSL https://raw.githubusercontent.com/trydirect/stacker/main/install.sh | bash\ncd my-project\nstacker init              # auto-detects project type, generates stacker.yml\nstacker deploy            # builds and runs locally via docker compose\nstacker status            # check running containers\n```\n\nGenerate a `stacker.yml`\n\nfrom a GitHub repository — no clone required.\nFor the best results (port mappings, env vars, service context inferred\nfrom README and source), use `--with-ai`\n\n:\n\n```\n# AI-powered (recommended — reads README, compose, source files)\nstacker init --from-github owner/repo --with-ai\n\n# Template-based (project type + Dockerfile detection only)\nstacker init -g https://github.com/ArchiveBox/ArchiveBox\n```\n\nWith `--with-ai`\n\n, Stacker shallow-clones the repo, then uses an LLM (Ollama\nby default) to scan project files and generate a context-aware `stacker.yml`\n\nwith services, ports, env vars, and healthchecks. Falls back to template\ndetection if the AI provider is unreachable.\n\nWhen environment variables are in the compose file, `.env.example`\n\nand\n`scripts/generate-secrets.sh`\n\nare also generated.\n\nStacker can scan your project files and use an LLM to generate a tailored `stacker.yml`\n\n:\n\n```\n# Local AI with Ollama (free, private, default)\nstacker init --with-ai\n\n# OpenAI\nstacker init --with-ai --ai-provider openai --ai-api-key sk-...\n\n# Anthropic (key from env)\nexport ANTHROPIC_API_KEY=sk-ant-...\nstacker init --with-ai --ai-provider anthropic\n```\n\nIf the AI provider is unreachable, Stacker falls back to template-based generation automatically.\n\nWhen the project looks like a simple HTML or Next.js website and the configured\nOllama model is `qwen2.5-code`\n\nor `qwen2.5-coder`\n\n, `stacker init --with-ai`\n\ncan also bootstrap a website deployment scenario. The bootstrap seeds values\nfrom the generated `stacker.yml`\n\n, asks only for the missing deploy inputs, and\nsaves scenario state under `.stacker/scenarios/qwen2.5-code/website-deploy/`\n\nfor later continuation with `stacker ai`\n\n.\n\nFor the canonical AI/MCP deployment flow — inspect state, explain topology or\nenv provenance, preview a plan, apply it safely, and recover with events or\nrollback — see [AI deployment workflows](/trydirect/stacker/blob/main/docs/AI_DEPLOYMENT_WORKFLOWS.md).\n\nFor the qwen-specific website scenario flow, including `--scenario`\n\nand `--step`\n\ncontinuation, see the same guide.\n\n```\nname: my-app\napp:\n  type: node\n  path: ./src\n  ports:\n    - \"8080:3000\"\n  environment:\n    NODE_ENV: production\n\nservices:\n  - name: postgres\n    image: postgres:16\n    environment:\n      POSTGRES_DB: myapp\n      POSTGRES_PASSWORD: ${DB_PASSWORD}\n\nproxy:\n  type: nginx\n  auto_detect: true\n  domains:\n    - domain: app.example.com\n      ssl: auto\n      upstream: app:3000\n\ndeploy:\n  target: local    # or: cloud, server\n\nai:\n  enabled: true\n  provider: ollama\n  model: llama3\n\nmonitoring:\n  status_panel: true\n  healthcheck:\n    endpoint: /health\n    interval: 30s\n```\n\nFull schema reference: [docs/STACKER_YML_REFERENCE.md](/trydirect/stacker/blob/main/docs/STACKER_YML_REFERENCE.md)\n\n| Component | What it does | Binary |\n|---|---|---|\nStacker CLI |\nDeveloper tool — init, deploy, monitor from the terminal | `stacker-cli` |\nStacker Server |\nREST API + Stack Builder UI + deployment orchestration + MCP Server | `server` |\nStatus Panel Agent |\nDeployed alongside your app on the target server — executes commands, streams logs, reports health | (separate repo) |\n\n```\n┌──────────────┐         ┌──────────────────┐         ┌─────────────────────┐\n│  Stacker CLI │────────►│  Stacker Server  │────────►│  Status Panel Agent │\n│              │  REST   │                  │  queue  │  (on target server) │\n│  stacker.yml │  API    │  Stack Builder UI│  pull   │                     │\n│  init/deploy │         │  85+ MCP tools   │◄────────│  health / logs /    │\n│  status/logs │         │  Vault · AMQP    │  HMAC   │  restart / exec /   │\n└──────────────┘         └──────────────────┘         │  deploy_app / proxy │\n                                │                     └─────────────────────┘\n                                ▼\n                    Terraform + Ansible ──► Cloud\n                    (Hetzner, DO, AWS, Linode)\n```\n\nThe end-user tool. No server required for local deploys.\n\n| Command | Description |\n|---|---|\n`stacker init` |\nDetect project type, generate `stacker.yml` + `.stacker/` artifacts |\n`stacker deploy` |\nBuild & deploy the stack (local, cloud, or server). Cloud deploys also install a local SSH backup key when possible. `--runtime kata|runc` selects container runtime |\n`stacker status` |\nShow running containers and health |\n`stacker logs` |\nView container logs (`--follow` , `--service` , `--tail` ) |\n`stacker secrets` |\nManage local `.env` secrets or remote Vault-backed `service` / `server` secrets |\n`stacker list deployments` / `stacker deployments` |\nList deployments on the Stacker server |\n`stacker list servers` / `stacker servers` |\nList saved servers |\n`stacker list clouds` / `stacker clouds` |\nList saved cloud credentials |\n`stacker list ssh-keys` / `stacker ssh-keys` |\nList per-server SSH key status |\n`stacker destroy` |\nTear down the deployed stack |\n`stacker config validate` |\nValidate `stacker.yml` syntax |\n`stacker config show` |\nShow resolved configuration |\n`stacker config example` |\nPrint a full commented reference |\n`stacker config setup cloud` |\nGuided cloud deployment setup |\n`stacker config setup ai` |\nConfigure AI provider, endpoint, model, and tasks |\n`stacker ai ask \"question\"` |\nAsk the AI about your stack |\n`stacker proxy add` |\nAdd a reverse-proxy domain entry |\n`stacker proxy detect` |\nAuto-detect existing reverse-proxy containers |\n`stacker cloud firewall add` |\nOpen cloud-provider firewall ports without SSH, for example `--public-ports 8000/tcp` on Hetzner |\n`stacker cloud firewall remove` |\nRemove Stacker-managed cloud-provider firewall rules |\n`stacker cloud firewall list` |\nList cloud-provider firewall rules for a server |\n`stacker ssh-key generate` |\nGenerate a new SSH key pair for a server (Vault-backed) |\n`stacker ssh-key show` |\nDisplay the public SSH key for a server |\n`stacker ssh-key upload` |\nUpload an existing SSH key pair for a server |\n`stacker ssh-key inject` |\nRepair Vault-key trust by using an already-working private key to update `authorized_keys` |\n`stacker service add` |\nAdd a service from the template catalog to `stacker.yml` |\n`stacker service list` |\nList available service templates (20+ built-in) |\n`stacker agent health` |\nCheck Status Panel agent connectivity and health |\n`stacker agent status` |\nDisplay agent snapshot — containers, versions, uptime |\n`stacker agent list apps` / `stacker agent apps` |\nList apps for the target deployment |\n`stacker agent list containers` / `stacker agent containers` |\nList containers on the target server |\n`stacker agent logs <app>` |\nRetrieve container logs from the remote agent |\n`stacker agent restart <app>` |\nRestart a container via the agent |\n`stacker agent deploy-app` |\nDeploy or update an app container on the target server. `--runtime kata|runc` selects container runtime; `--env <name>` selects the deploy environment/profile |\n`stacker agent remove-app` |\nRemove an app container (with optional volume/image cleanup) |\n`stacker agent configure-proxy` |\nConfigure Nginx Proxy Manager via the agent; use `--no-ssl` for plain HTTP hosts (credentials are resolved from Vault and are auto-seeded for managed Status Panel + NPM deploys) |\n`stacker agent configure-firewall` |\nConfigure guest OS firewall rules via the Status Panel agent; use `stacker cloud firewall` for provider firewalls |\n`stacker agent history` |\nShow recent command execution history |\n`stacker agent exec` |\nExecute a raw agent command with JSON parameters |\n`stacker pipe scan` |\nDiscover local endpoints/resources from running containers (when target is `local` ) |\n`stacker pipe scan --containers [filter]` |\nDiscover local endpoints/resources for matching containers |\n`stacker pipe scan --app <app>` |\nProbe a remote app for API endpoints |\n`stacker pipe create <src> <tgt>` |\nCreate a data pipe between two containers (interactive) |\n`stacker pipe list` |\nList pipe instances for the current deployment |\n`stacker pipe activate <id>` |\nActivate a pipe (start listening for triggers) |\n`stacker pipe deactivate <id>` |\nPause an active pipe |\n`stacker pipe trigger <id>` |\nOne-shot pipe execution with optional input data |\n`stacker pipe deploy <id>` |\nPromote a local pipe to a remote deployment |\n`stacker pipe history <id>` |\nView execution history for a pipe |\n`stacker pipe replay <exec-id>` |\nRe-run a previous pipe execution |\n`stacker target [local|cloud|server]` |\nSwitch deployment target mode |\n`stacker env [local|dev|prod]` |\nShow or persist the active deploy environment/profile used by app-only updates |\n`stacker whoami` |\nShow the active login, subscription plan, and current project deployment context |\n`stacker submit` |\nPackage current stack and submit to marketplace for review |\n`stacker marketplace status` |\nCheck submission status for your marketplace templates |\n`stacker marketplace logs <name>` |\nShow review comments and history for a submission |\n`stacker login` |\nAuthenticate with the TryDirect platform |\n`stacker update` |\nCheck for updates and self-update |\n\n```\nstacker deploy --target local     # docker compose up (default)\nstacker deploy --target cloud     # Terraform + Ansible → cloud provider\nstacker deploy --target server    # deploy to existing server via SSH\nstacker deploy --dry-run          # preview generated files without executing\n```\n\nAfter a successful cloud deploy, Stacker creates or reuses a local backup key at\n`~/.config/stacker/ssh/server-<id>_ed25519`\n\n(or under `$XDG_CONFIG_HOME`\n\n) and\nauthorizes its public key on the server when possible. The CLI prints a normal\n`ssh -i ...`\n\ncommand, while the Vault private key remains server-side.\n\nWhen a cloud/server deploy includes `deploy.registry`\n\ncredentials (or the\nequivalent `STACKER_DOCKER_*`\n\nenvironment variables), Stacker stores that\nregistry auth securely and reuses it for later Status-managed image refreshes\nsuch as `stacker agent deploy-app`\n\n. This keeps private-image redeploys working\nwithout depending on host-level `docker login`\n\nstate or mounting `/root/.docker`\n\ninto the agent container.\n\n```\n# Local project .env secret\nstacker secrets set DB_PASSWORD=supersecret\n\n# Discover valid remote deployable service/app targets first\nstacker secrets apps\n\n# Remote service secret used at render/deploy time for one target\nstacker secrets set S3_SECRET_KEY \\\n  --scope service \\\n  --service uploader \\\n  --body supersecret\n\n# Remote server secret for future host-level consumers\nstacker secrets set NPM_TOKEN \\\n  --scope server \\\n  --server-id 42 \\\n  --body-file .npm-token\n\n# Remote reads are metadata-only in v1\nstacker secrets list --scope service --service uploader --json\nstacker secrets get S3_SECRET_KEY --scope service --service uploader --json\n\n# Push stored remote secrets into the target's runtime env\nstacker secrets push --service uploader\nstacker secrets push --service uploader --env prod\n# Aliases: stacker secrets deploy --service uploader\n#          stacker secrets apply --service uploader\n```\n\n- Local mode remains the default and reads/writes the project\n`.env`\n\nfile. - Remote mode is enabled only with\n`--scope service`\n\nor`--scope server`\n\n. - Service-scoped remote commands default\n`--project`\n\nfrom`stacker.yml -> project.identity`\n\n;`--project`\n\nstill overrides it explicitly. - Service-scoped secrets target deployable service/app codes listed by\n`stacker secrets apps`\n\n, including registered`stacker.yml`\n\nservices and supported image-backed Compose services after a deploy/update sync. - Service-scoped secrets are merged only into the matching rendered service/app env at deploy time.\n`stacker secrets push --service <target>`\n\napplies stored service secrets to the remote runtime env without changing secret values. Use`--env <name>`\n\nfor a one-off environment selection, or`stacker env <name>`\n\nto persist the active environment/profile for future app-only updates. Use`--force`\n\nonly when the remote env drift check reports an out-of-band change.- Remote\n`get`\n\nand`list`\n\ndo**not** return plaintext values in v1. - MCP env inspection now exposes explicit secure metadata for Vault-backed\nvariables:\n`get_app_env_vars`\n\nkeeps the redacted`environment_variables`\n\nobject for compatibility and also returns`environment_entries[]`\n\nwith`secure`\n\n,`redacted`\n\n, and`source`\n\nfields.\n\nRemote deploys render runtime env into one canonical host file:\n`/home/trydirect/project/.env`\n\n. Generated compose uses `env_file: .env`\n\n, so the\npath is relative to the deployed compose file. To inspect paths and contributing\nlayers without exposing values, run:\n\n```\nstacker config show --resolved\n```\n\nFor app-only updates, `stacker agent deploy-app <target>`\n\nresolves the deploy\nenvironment from `--env`\n\n, then `.stacker/active-env`\n\n, then `stacker.yml`\n\n. If\n`<target>/docker/<env>/compose.yml`\n\nexists, Stacker uses the app-local service\ndefinition for that target but merges it into the full project-level compose\nfile before sending it to the agent. This prevents app-only updates from\nreplacing the remote stack compose with a single-service compose file. Any\napp-local `.env`\n\nreferenced by that compose file is uploaded in the config\nbundle, and Stacker appends the Vault-rendered service secrets for the same\ntarget to that file before the agent writes it on the server. Repeated app-only\nupdates replace the prior `# stacker-render ...`\n\nblock in that file instead of\nstacking duplicate rendered secret sections.\n\n```\nstacker deploy --target local           # 1. test locally\nstacker deploy --target server          # 2. test on remote server\nstacker submit                          # 3. submit for marketplace review\nstacker marketplace status              # 4. check review status\n# Stack is auto-published once approved by the review team\n# Option A: Deploy from your laptop to a remote server\nstacker deploy my-stack --target server --host 1.2.3.4\n\n# Option B: Run directly on the target server (one-liner)\ncurl -sL https://marketplace.try.direct/<purchase-token>/install.sh | sh\n```\n\n**Auto-detection**— identifies Node, Python, Rust, Go, PHP, static sites from project files** Dockerfile generation**— produces optimised multi-stage Dockerfiles per app type** Docker Compose generation**— wires app + services + proxy + monitoring** Remote service secrets**— Vault-backed service/app target secrets are metadata-only when read and isolated to the selected service** AI-assisted config**— scans project, calls LLM to generate tailored`stacker.yml`\n\n**AI troubleshooting**— on deploy failure, suggests fixes via AI or deterministic fallback hints** Service catalog**— 20+ built-in service templates (Postgres, Redis, WordPress, etc.) — add with`stacker service add`\n\n**AI service addition**— ask`stacker ai ask --write \"add wordpress\"`\n\nand the AI uses the template catalog**Agent control**—`stacker agent`\n\nsubcommand to manage remote Status Panel agents (health, logs, restart, deploy, proxy) with`--json`\n\noutput**SSH key management**— generate, view, upload, and repair server SSH keys (Vault-backed), with automatic local backup SSH access after cloud deploy**Reverse proxy**— auto-detects Nginx / Nginx Proxy Manager, configures domains + SSL** Cloud deployment**— Hetzner, DigitalOcean, AWS, Linode, with provider firewall operations and paused/failed install IP retention** MCP Server**— 85+ tools, including deployment, agent control, config, proxy, firewall, and remote service secret management** Marketplace**— submit stacks for review, auto-publish on approval, check status from CLI** Buyer install**— purchase tokens, one-liner install scripts, agent self-registration\n\nThe backend platform powering the Stack Builder UI, REST API, deployment orchestration, and MCP server for AI agents.\n\n```\ncp configuration.yaml.dist configuration.yaml   # edit database, vault, AMQP settings\ncp access_control.conf.dist access_control.conf\nexport DATABASE_URL=postgres://postgres:postgres@localhost:5432/stacker\nsqlx migrate run\ncargo run --bin server                           # http://127.0.0.1:8000\n```\n\n| Endpoint | Description |\n|---|---|\n`POST /project` |\nCreate a project from a stack definition |\n`POST /{id}/deploy/{cloud_id}` |\nDeploy to a cloud provider |\n`GET /project/{id}/apps` |\nList apps in a project |\n`DELETE /project/{id}/apps/{code}` |\nRemove an app from a project |\n`PUT /project/{id}/apps/{code}/env` |\nUpdate app environment variables |\n`GET /project/{id}/apps/{code}/secrets` |\nList service-scoped secret metadata for an app |\n`PUT /project/{id}/apps/{code}/secrets/{name}` |\nCreate or update a Vault-backed service secret |\n`PUT /project/{id}/apps/{code}/ports` |\nUpdate port mappings |\n`PUT /project/{id}/apps/{code}/domain` |\nUpdate domain / SSL settings |\n`GET /server/{id}/secrets` |\nList server-scoped secret metadata |\n`PUT /server/{id}/secrets/{name}` |\nCreate or update a Vault-backed server secret |\n`POST /api/v1/commands` |\nEnqueue a command for the Status Panel agent |\n`POST /api/templates` |\nCreate or update a marketplace template (creator) |\n`POST /api/templates/{id}/submit` |\nSubmit template for marketplace review |\n`GET /api/templates/mine` |\nList current user's template submissions |\n`GET /api/v1/marketplace/install/{token}` |\nGenerate install.sh script for buyers |\n`GET /api/v1/marketplace/download/{token}` |\nDownload stack archive (purchase token validated) |\n`POST /api/v1/marketplace/agents/register` |\nAgent self-registration after install |\n`POST /api/v1/pipes/templates` |\nCreate a reusable pipe template (source→target mapping) |\n`GET /api/v1/pipes/templates` |\nList pipe templates (with optional filters) |\n`POST /api/v1/pipes/instances` |\nCreate a pipe instance for a deployment |\n`GET /api/v1/pipes/instances` |\nList pipe instances by deployment hash |\n`PUT /api/v1/pipes/instances/{id}/status` |\nUpdate pipe instance status (active/paused) |\n\nStacker exposes **52+ Model Context Protocol tools** over WebSocket, enabling AI agents (Claude, GPT, etc.) to manage infrastructure programmatically:\n\n- Project & deployment management\n- Container operations (start, stop, restart, exec)\n- Log analysis & error summaries\n- Vault config read/write\n- Proxy configuration\n- App environment & port management\n- Server resource monitoring\n- Docker Compose generation & preview\n- Agent control (deploy app, remove app, configure proxy, get status)\n- Firewall management (iptables rules via Status Panel or SSH)\n\n**HashiCorp Vault**— secrets and config storage, synced to deployments** RabbitMQ**— deployment status updates, event-driven orchestration** TryDirect User Service**— OAuth, marketplace templates, payment validation** Marketplace**— publish and deploy community stacks\n\nA lightweight agent deployed alongside your application on the target server. It runs as a Docker container and communicates with Stacker Server using a **pull-only architecture** — the agent polls for commands, Stacker never dials out.\n\n```\n1. UI/API creates a command       →  POST /api/v1/commands\n2. Command stored in DB queue     →  commands + command_queue tables\n3. Agent polls for work           →  GET /api/v1/agent/commands/wait/{hash}\n4. Agent executes locally         →  Docker API on the host\n5. Agent reports result           →  POST /api/v1/agent/commands/report\n```\n\nAll agent requests are **HMAC-signed** (`X-Agent-Signature`\n\nheader) using a token stored in Vault.\n\n| Command | Description |\n|---|---|\n`health` |\nCheck container health status (single or all) |\n`logs` |\nFetch container logs (stdout/stderr, with limits) |\n`restart` |\nRestart a container |\n`deploy_app` |\nDeploy or update an app container |\n`remove_app` |\nRemove an app container |\n`configure_proxy` |\nCreate/update/delete reverse-proxy entries |\n`configure_firewall` |\nConfigure iptables firewall rules (add/remove/list/flush) |\n`stacker.exec` |\nExecute a command inside a running container (with security blocklist) |\n`stacker.server_resources` |\nCollect server resource metrics (CPU, memory, disk, network) |\n`apply_config` |\nPull config from Vault and apply to a running container |\n`probe_endpoints` |\nDiscover API endpoints on containers (OpenAPI, REST, HTML forms, GraphQL) |\n`activate_pipe` |\nActivate a pipe instance — start polling/webhook triggers |\n`deactivate_pipe` |\nDeactivate a running pipe instance |\n`trigger_pipe` |\nOne-shot pipe execution: fetch source data → map fields → post to target |\n\n```\n# Agent self-registers on first boot (no auth required)\nPOST /api/v1/agent/register\n  { \"deployment_hash\": \"abc123\", \"capabilities\": [...], \"system_info\": {...} }\n  → { \"agent_id\": \"...\", \"agent_token\": \"...\" }\ncargo run --bin console -- Agent rotate-token \\\n  --deployment-hash <hash> \\\n  --new-token <NEW_TOKEN>\nsqlx migrate run      # apply\nsqlx migrate revert   # rollback\ncargo test                         # all tests (772+ unit, 69 security integration)\ncargo test user_service_client     # User Service connector\ncargo test marketplace_webhook     # Marketplace webhook flows\ncargo test deployment_validator    # Deployment validation\ncargo test --test security_cli     # CLI endpoint IDOR security tests\n```\n\nStacker supports [Kata Containers](https://katacontainers.io/) as an alternative runtime, providing VM-level isolation for each container using hardware virtualization (KVM).\n\n**KVM requirement** — Kata needs nested or bare-metal KVM. Hetzner dedicated-CPU servers (CCX line) expose `/dev/kvm`\n\nout of the box, making them an ideal deployment target.\n\n```\nstacker deploy --runtime kata          # deploy the current stack with Kata isolation\nstacker agent deploy-app --runtime kata  # deploy a single app container with Kata\n```\n\nSee [docs/kata/](/trydirect/stacker/blob/main/docs/kata/README.md) for the full setup guide, network constraints, and monitoring reference. Automated provisioning (Ansible + Terraform for Hetzner CCX) is available via the TFA infrastructure toolkit.\n\n[stacker.yml reference](/trydirect/stacker/blob/main/docs/STACKER_YML_REFERENCE.md)— full configuration schema[CLI implementation plan](/trydirect/stacker/blob/main/docs/STACKER_CLI_PLAN.md)— architecture and design decisions[Changelog](/trydirect/stacker/blob/main/CHANGELOG.md)— release history[Kata Containers guide](/trydirect/stacker/blob/main/docs/kata/README.md)— hardware-isolated containers with KVM", "url": "https://wpnews.pro/news/stacker-deploy-multi-container-docker-stacks-with-one-cli-command", "canonical_source": "https://github.com/trydirect/stacker", "published_at": "2026-07-21 08:10:54+00:00", "updated_at": "2026-07-21 08:23:01.514551+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "ai-tools"], "entities": ["Stacker", "Ollama", "OpenAI", "Anthropic", "GitHub", "Docker"], "alternates": {"html": "https://wpnews.pro/news/stacker-deploy-multi-container-docker-stacks-with-one-cli-command", "markdown": "https://wpnews.pro/news/stacker-deploy-multi-container-docker-stacks-with-one-cli-command.md", "text": "https://wpnews.pro/news/stacker-deploy-multi-container-docker-stacks-with-one-cli-command.txt", "jsonld": "https://wpnews.pro/news/stacker-deploy-multi-container-docker-stacks-with-one-cli-command.jsonld"}}