New Feature: Instantly Clone Your Service
What is the Clone Service Feature?
Up until now, Qovery users were able to clone a complete environment. This feature, one of the most popular, was leveraged by teams who needed to duplicate an environment for testing, benchmarking, demos, sales purposes, and more, without impacting the original environment. It's the Clone Environment feature that is used behind the powerful Preview Environment feature from Qovery.
Today, we've taken it a step further with the ability to clone an individual service from one environment to another, within the same environment, or even within another environment inside another project. That's right, we've lit the 🔥 and amplified the capacity of our platform!
For a detailed understanding of the difference between Clone Service and Clone Environment, we recommend this comprehensive video: Clone Service vs Clone Environment.
How Does the Clone Service Feature Work?
With the Clone Service feature, users can now duplicate a service effortlessly. It smartly clones all the necessary properties, such as environment variables, secrets, resources settings, and advanced settings, ensuring that your duplicated service retains the core of the original. However, it wisely leaves out the settings that cannot be duplicated across services, like the custom domain.
Watch this video to get a quick overview of the Clone Service feature.
Why Clone a Service?
With the Clone Service feature, our users can create replicas of their services instantly, streamlining their workflow and accelerating their development process.
This feature is particularly beneficial when teams need to duplicate a particular service multiple times for various purposes without needing to clone the entire environment. It saves time, improves efficiency, and mitigates risks by allowing users to perform actions on the cloned service without affecting the original one. But here a non-exhaustive list of appropriate use cases for the Clone Service feature:
- Individual Service Testing: While Clone Environment is perfect for comprehensive testing, Clone Service allows you to focus solely on a specific service. This approach is not only more efficient but also significantly more cost-effective.
- Bug Reproduction and Debugging: Isolating a faulty service by cloning it helps to focus the debugging efforts and reduces the resources needed compared to cloning the entire environment.
- Performance Benchmarking: Cloning individual services allows you to tweak and optimize their performance without the overhead costs of duplicating the whole environment.
- Demo Purposes: In sales or client demos, you might only need to showcase a specific service. Cloning just this service saves unnecessary expenditure on environment duplication.
- Education and Training: Trainees can learn and experiment on a cloned service rather than a full environment, reducing training costs and resource usage.
- Microservice Architecture: For applications using a microservice architecture, cloning individual services is significantly more cost-effective than cloning the entire environment.
- Environment Cleanliness: Cloning only the necessary services helps keep your environments clean and organized, and is also a more economical use of resources.
- Cost-Efficiency: One of the major advantages of the Clone Service feature is its cost-effectiveness. Cloning a whole environment can rack up costs, especially for larger, more complex environments. By allowing users to clone individual services, you can significantly reduce costs while still achieving your objectives.
By bringing the cost-effectiveness of service cloning to the forefront, we've highlighted another significant advantage of the Clone Service feature. Balancing cost with development requirements is crucial, and this feature offers an efficient way to maintain this balance.
The Takeaway
The Clone Service feature is yet another step in Qovery's commitment to facilitating a smooth and efficient development process for our users. It not only broadens the capabilities of our platform but also empowers users to manage their environments and services more flexibly.
We are thrilled to see this feature in action and look forward to hearing your experiences. So, go ahead and start cloning your services, and remember, we're here to assist you every step of the way!
.svg)
.svg)
.svg)
Suggested articles
The cluster coming up is the easy part. What catches teams off guard is what happens six months later: certificates expire without a single alert, node pools run at 40% over-provisioned because nobody revisited the initial resource requests, and a manual kubectl patch applied during a 2am incident is now permanent state. Agentic control planes enforce declared state continuously. Monitoring tools just report the problem.
The instinct when setting up Kubernetes observability is to instrument everything and send it all to your APM vendor. That works fine at ten nodes. At a hundred, the bill becomes a board-level conversation. The less obvious problem is the fix most teams reach for: aggressive sampling. That is how intermittent failures affecting 1% of requests disappear from your monitoring entirely.
Scaling your deployments to zero is only half the battle. If your cluster autoscaler does not aggressively bin-pack and terminate the underlying worker nodes, you are still paying for idle metal. True environment sleeping requires tight integration between your ingress layer and your node provisioner to actually realize FinOps savings.
The structure, table, tool list, and code blocks are all worth keeping. The main work is fixing AI-isms in the prose, updating the case study to real metrics, correcting the FAQ format, and replacing the CTAs with the proper HTML blocks. The tool descriptions need the "Core strengths / Potential weaknesses" headers made less template-y, and the intro needs a sharper human voice.
For years, Red Hat OpenShift has been the safe choice for heavily regulated, on-premise environments. It operates as a secure fortress. But in the public cloud, that fortress acts as an expensive prison. Paying proprietary per-core licensing fees on top of your standard AWS or GCP compute bill is a redundant "middleware tax." Escaping OpenShift requires decoupling your infrastructure from your developer experience by running standard, vanilla Kubernetes paired with an agentic control plane.
Agentic Kubernetes resource reclamation is the practice of using an autonomous control plane to continuously identify, suspend, and delete idle infrastructure across a multi-cloud Kubernetes fleet. It replaces manual cleanup and reactive autoscaling with intent-based policies that act on business state, eliminating the configuration drift and cloud waste typical of unmanaged fleets.
Kubernetes focuses on container orchestration, but the reality on the ground is far less forgiving. Provisioning a single cluster is a trivial Day-1 exercise. The true operational nightmare begins on Day 2. Teams that treat multi-cloud fleets like isolated pets inevitably face crushing YAML configuration drift, runaway AWS bills, and severe scaling bottlenecks.
.webp)