Portainer Release Notes

Release v1.34.1

Bug Fixes

• portainer_stack: honor active = false on create (#134) — a stack created with active = false is now stopped right after deployment instead of coming up running. Previously the flag was only applied on update, so a new stack always started, and with ignore_changes = [active] it never stopped at all.

Internal / Maintenance

• Unify direct-HTTP call sites behind a single doJSON helper (auth + status + JSON decode) across 97 files, with typed API errors and 404 handling.
• Add a table-driven CRUD test harness (crudCase).
• Add a schema↔docs drift-check linter as a new CI guard.
• Parallelize the e2e CI pipeline (shared composite setup action + split docker/kubernetes/swarm, edge and ssl jobs).

Documentation

• Document previously-missing schema fields: portainer_edge_stack.always_clone, portainer_settings.black_listed_labels, portainer_settings.edge_portainer_url.

2.43.3 — Targets Portainer 2.43.x

Added

• Configurable upstream timeout (PORTAINER_TIMEOUT, seconds) — #80. The upstream Portainer HTTP timeout was hardcoded at 30s, routinely too short for stack creation (Portainer deploys synchronously — the request holds open through image pull and compose up). The default rises to 120s, the connect phase stays capped at 10s so an unreachable Portainer still fails fast, and the knob applies to both transports. Non-numeric or non-positive values refuse to boot; the resolved posture is logged at startup.

Changed

• Post-send timeouts now say the write may have succeeded (#80). A request that times out after reaching Portainer is ambiguous, not failed — Portainer keeps processing, which is how two timed-out stack creates left two stack records behind in #80. FastMCP's stock error ("please retry") invites exactly the duplicate-creating reflex, so ReadTimeout/WriteTimeout errors are rewritten to name the ambiguity, instruct the model to verify current state (e.g. StackList) before retrying, and point at PORTAINER_TIMEOUT. Connect-phase timeouts are left untouched — the request never reached Portainer.

Full changelog: https://github.com/portainer/portainer-mcp/blob/2.43.3/CHANGELOG.md

2.43.2 — Targets Portainer 2.43.x

Fixed

• Guidance gate no longer keys on Mcp-Session-Id — clients behind session-churning bridges are never locked out (#75). The gate is now a toll booth: the first tool call from a caller whose idle window has lapsed is answered with the operating guide itself (plus a retry instruction) instead of a "call get_guidance and retry" bounce, and the caller is marked guided immediately — delivery is the proof, so nothing needs to be correlated across requests and there is no lockout state. Callers are identified by the authenticated principal (the per-user API-key digest over HTTP, the process over stdio), the scoping SEP-2567 recommends now that major clients mint a fresh session id per tool call. The window slides with activity (PORTAINER_MCP_GUIDANCE_TTL, default 1800s), so re-delivery happens on the next conversation, not mid-task — including over stdio, where the old gate fired only once per process lifetime. PORTAINER_MCP_DISABLE_GUIDANCE_GATE=1 disables enforcement entirely (install the hygiene skill manually on clients in that case); get_guidance remains available on demand.

Added

• Trust-proxy auth posture (PORTAINER_MCP_TRUST_PROXY_AUTH=1) for deployments behind an identity-aware proxy that owns the Authorization header (e.g. Pomerium in MCP server mode) — #76. The gate-token compare is replaced by per-request proxy attestation: inherited from the …

Release v1.34.0

Features

• Proxy support: the provider now honors the standard HTTP_PROXY / HTTPS_PROXY / NO_PROXY environment variables when connecting to the Portainer endpoint. No-op when unset, so existing setups are unaffected. (#131)
• portainer_stack: new source_id attribute for Portainer 2.43 STS, which replaced shared Git credentials with the Sources model. Both source_id (2.43+) and repository_git_credential_id (< 2.43) are sent, so one configuration works against old and new Portainer. (#132)

Fixes

• portainer_stack: deploying a Git stack against Portainer 2.43 STS no longer fails with "Password must be specified when authentication is enabled"; set source_id (or fall back to inline repository_username/password). (#132)

Internal / Maintenance

• Centralized duplicated auth-header and d.Set handling into shared helpers (setAuthHeader, setFields); no behavior change.
• Raised unit-test coverage from ~77% to 85%.

July 14, 2026

Known Issues

• On Async Edge environments, an invalid update schedule date can be displayed when browsing a snapshot
• kubectl port-forward fails with Portainer kubeconfig in some configurations

Known issues with Podman

• Support for only CentOS 9, Podman 5 rootful
• Auto onboarding a Podman environment defaults to “Standard” and not “Podman”
• It's not possible to add Podman environments via socket, when running a Portainer server on Docker (and vice versa)

Known issues with Talos clusters managed by Omni (BE only)

• Loading Omni specific information in the Cluster Details view and configuring an existing Talos cluster is currently restricted to Portainer Admins. Environment Admins will get a forbidden error when attempting to do this. This only applies to Omni configuration, and does not affect authentication for any other functionality in the cluster

New in this Release

• Fixed a 2.39.4 regression where a relative env_file: in a Git stack whose compose file lives in a repository sub-directory was resolved against the project root instead of the compose file's own directory, deploying stacks with an empty environment or failing outright
• Improved Edge tunnel reliability over high-latency links (satellite/VSAT): the server no longer tears down a half-established tunnel on timeout, keep-alive and unlimited background retries were added on the agent, and the ping timeout was raised from 3s to 8s …

Known issues

• On Async Edge environments, an invalid update schedule date can be displayed when browsing a snapshot

Known issues with Podman support

• Podman environments aren't supported by auto-onboarding script
• It's not possible to add Podman environments via socket, when running a Portainer server on Docker (and vice versa)
• Support for only CentOS 9, Podman 5 rootful

Changes

• Fixed a 2.39.4 regression where a relative env_file: in a Git stack whose compose file lives in a repository sub-directory was resolved against the project root instead of the compose file's own directory, deploying stacks with an empty environment or failing outright
• Improved Edge tunnel reliability over high-latency links (satellite/VSAT): the server no longer tears down a half-established tunnel on timeout, keep-alive and unlimited background retries were added on the agent, and the ping timeout was raised from 3s to 8s
• Fixed standard users not seeing all of their teams in access control selectors (e.g. when restricting access on a newly created Docker Config), caused by FilterUserTeams incorrectly dropping teams
• Fixed deleting images from the Swarm image list only removing them from a single node instead of every node they exist on
• Fixed a potential block where a Docker stack deployment exceeding the internal 15-minute timeout left the stack stuck in "Deploying" status, preventing further redeployments …

What's Changed

Feature

• Added --node-ip flag (env KUBESOLO_NODE_IP) to pin the node IP on multi-NIC hosts #167
  • Applies to the apiserver advertise-address, kubeconfig, kubelet node IP, and LoadBalancer EXTERNAL-IP

Fixes

• Fixed an issue where a node IP change regenerated the entire PKI tree including the CA, invalidating previously distributed kubeconfigs — the CA is now preserved and only leaf certificates are re-signed #167
• Fixed non-deterministic node IP auto-detection on multi-NIC hosts, now preferring a private (RFC 1918) address #167 Chore
• Removed the edge memory overrides; KubeSolo now always uses upstream Kubernetes and containerd defaults #166

Full Changelog: https://github.com/portainer/kubesolo/compare/v1.1.7...v1.1.8