Hey Team,

This week's release is packed across a few different areas: more capability in RDE for teams building with AI agents, a new ephemeral shell mode for production-safe troubleshooting, and a security improvement for GCP clusters. There is also an important deadline to be aware of: NGINX support ends on August 31, 2026.

🤖 RDE improvements: bigger uploads, cleaner publish flow, and instant preview sharing

RDE is the product we are building together with customers to let non-technical users build and ship applications in a controlled environment. The goal is to bring the right guardrails so anyone on the team can contribute to software delivery without needing to understand Git or infrastructure.

This week we shipped three improvements that make the day-to-day experience noticeably smoother.

Larger file uploads. The maximum file size for uploads is now 50 MB, which covers the majority of real-world assets without requiring workarounds.

Simplified publish flow. Previously, users had to think about Git commits as a separate step. Now, when a user clicks "Publish", RDE handles the entire commit and pull request creation automatically. The user never has to leave the product to push their work upstream.

Share a preview instantly. A new "Share" option lets users expose a private preview over the internet with a single click. The link can be sent to colleagues for review without any additional infrastructure setup.

🐚 Ephemeral shell: production-safe troubleshooting without touching the live pod

When something goes wrong in production, the instinct is to open a shell inside the running pod. That works, but it carries risk: you are inside a live process, and any mistake can affect real traffic.

The new ephemeral shell mode takes a different approach. Instead of attaching to an existing pod, Qovery starts a temporary isolated pod built from the same service image and environment variables. When you close the session, the pod is automatically deleted. You get the exact runtime context you need without any exposure to the live application.

This is especially useful for running database migrations, executing one-off scripts, checking environment configuration, or any task where you want production-like conditions without production-level risk.

The ephemeral shell is available directly from the Qovery console and via the CLI:

qovery shell --ephemeral --mode clone <qovery_console_service_url>

When you need more headroom for a migration or heavy data operation, you can override the resource allocation:

qovery shell --ephemeral --mode clone --memory 2Gi --cpu 1 <qovery_console_service_url>

🔒 GCP WIF: Workload Identity Federation for GCP clusters

Qovery clusters deployed on GCP now use Workload Identity Federation (WIF) for authentication. WIF replaces long-lived service account keys with short-lived, automatically rotated credentials that are tied to the workload identity. This removes a class of credential exposure risk and aligns with Google's recommended security posture for production GCP workloads.

If you are setting up a new GCP cluster, you can add new credentials using the WIF method. If you are an existing customer, you can switch to WIF credentials at any time from your cluster settings in the Qovery console.

⚠️ NGINX deadline: support ends August 31, 2026

Earlier this year we announced the migration from NGINX Ingress to Envoy and the Gateway API. We originally planned to enforce the cutoff in June but chose to extend the window to give everyone more time to validate their applications on the new stack.

As a reminder, the NGINX Ingress project was archived by the upstream community in March 2026 and is no longer receiving updates. Keeping it in place beyond the cutoff date is not something we can support long-term.

NGINX support on Qovery clusters will be discontinued on August 31, 2026. If you have not migrated yet, we strongly recommend starting now. Migrating on your own timeline means you can test thoroughly and catch any routing or configuration differences without last-minute pressure.

The full migration guide is available at nginx-ingress-controller-migration. If you run into any issues during testing, reach out to the Qovery team and we will help you through it.

🛠️ Minor updates

  • Skill usage is now recorded in the audit logs. Teams using Qovery Copilot now have full visibility into which skills were invoked and when, which is useful for compliance and internal review.
  • The Secret Manager integration can now be configured via the Qovery Terraform provider, making it easier to manage secrets as part of your infrastructure-as-code workflows.
  • New advanced Envoy setting: envoy.client_validation.ca_certificates allows you to configure TLS client certificate validation directly in Envoy.
  • New documentation on securing AI agent access to Qovery covers how to safely expose Qovery to AI agents and copilots with the right permission boundaries.
  • The CLI now supports read-only Kubernetes access. You can generate a short-lived, scope-limited kubeconfig or token with qovery cluster kubeconfig --cluster-id <cluster_id> --read-only. Useful for support, audits, security reviews, or external operators who need visibility without admin-level access.

🔭 What's coming next

We are working on Qovery Blueprints, a curated library of infrastructure components maintained by the Qovery team. The first set will cover the most commonly requested resources: RDS PostgreSQL, S3 buckets, Redis, and more. Each blueprint will be versioned and configurable, so you can deploy a production-ready component with sensible defaults while still being able to tune the settings that matter for your workload. Because blueprints are versioned, Qovery can ship improvements over time and you can adopt them on your own schedule.

If you want early access or want to influence which components we prioritize, reach out to your CSM.

We hope these updates make your experience with Qovery better. The August 31 NGINX deadline is the one item worth acting on soon if you have not started the migration yet.

Talk soon, The Qovery Team 🚀