One post tagged with "API"

Version v3.1.5 closes out the 3.1 line. It adds no new product surface - it makes the surface added in v3.1.0 and v3.1.2 behave consistently. The admin REST API now matches the panel and its own documentation, load balancer routing and Proxmox firewall synchronization are more dependable, alert mail is delivered on its own queue, and every instance operation is fully localized. A platform review ran alongside this work; its outcomes are folded into the items below.

Upgrading is routine. There is nothing to reconfigure and no behavior to relearn.

• [Improvement] Admin REST API consistency - updating a user no longer requires resending a password, the acting administrator resolves the same way on every endpoint, and account credentials are excluded from responses. Load balancer security group rules are readable from the administrative API.
• [Improvement] Load balancer routing rules honor catch-all matches, applied after the specific rules and before the default backend, so precedence follows the order the rule list reads.
• [Improvement] Proxmox security group synchronization converges reliably, so firewall rule changes reach running VMs on every cycle, and an explicit deny takes precedence over a broader allow.
• [Improvement] Notification and alert mail - certificate lifecycle notices, autoscaler token renewals, the admin income digest, and invoice issuance now use the dedicated notifications queue rather than sharing one with live dashboard traffic.
• [Improvement] Full localization of instance operations, with a build-time guard so a new action cannot ship without its wording.
• [Improvement] Quota enforcement is identical from the panel and the API, and quota messages distinguish being at your limit from a brief collision with your own concurrent request.
• [Security] Tighter tenant boundaries on object storage keys and volume plans, stricter identity binding for cluster nodes, and payment capture bound to its originating transaction.
• [Security] Cluster join credentials are cleared on every terminal outcome, with kubernetes:scrub-cloudcfg provided for existing installs.
• [Operations] Managed MariaDB monitoring, scheduler health naming, and a single pinned PHP runtime for workers and cron.

Since v3.1.0​

If you are upgrading from the 3.0 line, the two releases between it and this one carry the feature work:

• v3.1.0 adds native Proxmox VE support. Point the platform at an existing PVE 8 or 9 node or cluster with a single API token and manage it beside your KVM fleet - deploys, VPC networking, security groups, backups, snapshots, live migration, consoles, HA, Docker, managed databases, load balancers, Kubernetes, and exact per-NIC bandwidth metering. Agentless, over the Proxmox API.
• v3.1.2 adds OAuth sign-in with Google, Microsoft and GitHub, enforceable admin OIDC single sign-on, private locations with a built-in request-access workflow, a per-node deployment readiness engine surfaced on the dashboard, the hypervisor list and each node's detail page, and a substantially tougher load balancer with static-IP deploys, captured error state, and long-lived TCP session support.

v3.1.5 builds directly on both: the Proxmox firewall and load balancer improvements below apply to the surfaces those releases introduced.

Kubernetes cluster credential hygiene​

Cluster join credentials are meant to be short-lived - they exist while a node is joining and are cleared once it settles. That clearing now runs on every terminal outcome, so a node that fails to join is cleaned up exactly like one that succeeds, and it runs from the periodic reconcilers as well as the join callback, covering a node that never reports back.

Because the behavior changed, v3.1.5 ships php artisan kubernetes:scrub-cloudcfg for existing installs. It is a dry run by default and requires an explicit --force to write, only touches clusters that are fully destroyed, holds a settle window on top of that, includes soft-deleted records, and logs everything it does. Operators upgrading from an earlier 3.1.x can run it once; new installs never accumulate this data.

Admin REST API​

Several /api/v1 endpoints behaved differently from the panel and from their own documentation. They now agree:

• Updating a user no longer requires a password. You can change a name, a role, or a quota without sending a credential, and an unchanged email address is accepted.
• The acting administrator resolves consistently across instance image listing, user update and delete, VPC enable and disable, and backup creation.
• Account secrets never appear in responses - API credentials and multi-factor state are excluded from every serialized user object, and the published examples match.

The API manifest, the OpenTofu provider, and the MCP server coverage gates remain in lockstep at 889 endpoints, verified in CI.

Tenant boundaries​

Object storage access keys resolve strictly within the owning account on every user-facing route, while the administrative surface keeps its intentionally cross-account view. Volume plans are enforced against the region that offers them, so a plan wired to one location cannot be provisioned into another and pricing stays aligned with your catalog. Cluster node identity is derived solely from the signed token a node presents when it joins.

None of this requires a schema change or any action on your part.

Localization​

Every user-facing string in the instance operation pipeline is now translatable, including task names and result messages assembled at runtime. A build-time guard reads the accepted actions directly from the service and fails the build if any of them lacks its wording, so the coverage cannot silently regress.