Your application is online, users are using it, and everything works. Then you have a new version to publish — a bug fix, a new feature, or simply an improvement — and the same question comes back every time: do I need to stop my application while I deploy the new version?
For a small personal application, it may not be a big deal. But when real users depend on your application, even a short interruption can be inconvenient. That is where Qeda Push comes in.
The idea is simple: you send your new version to Qeda, and the platform handles the deployment without asking you to intentionally shut down your application. In this tutorial, we will see how to use Qeda Push to publish a new version of your application with minimal interruption.
Your application is already on Qeda
To get started, you need an application already deployed on Qeda — for example, at https://my-app.qeda.app. Simply open the URL and check that it works: you already have your first version in production. Open your service card from the dashboard and you will see it marked Running — that green badge is the state you want to see before touching anything. Now you want to publish version 2.
Make your change
Imagine you have just added a new feature. It could be:
- a new page
- a new button
- an improvement to your API
- a bug fix
- a new user-facing feature
You work normally on your project, and once your change is complete, you test it locally. The goal is simple: make sure your new version works before publishing it.
Send your new version with Qeda Push
Once your code is ready, use Qeda Push to send your new version — your code becomes a new version, and that new version becomes the application in production. You do not need to manually manage the servers running your application: Qeda detects your stack and builds it with Cloud Native Buildpacks, so there is no Dockerfile to write or maintain. While it works, the status badge on your service walks through Building and then Running, so you always know exactly where your deployment stands.
Your application stays available
This is the important point: while your new version is being prepared, the goal is to keep the current application available for your users. They do not need to know that a deployment is in progress — for them, your application simply keeps working. Version 1 keeps serving traffic while Version 2 is prepared, sandboxed at the kernel level with gVisor, right up until the new one is ready to take over.
When the new version is ready, Qeda switches over to it — no maintenance page, no restart, no downtime window. That is the whole difference between a classic deployment and Qeda Push: one interrupts your users, the other doesn't.
Check your new version
Once the deployment is complete, open your application — for example, at https://my-app.qeda.app — and check that your new feature works. You can also test your API directly:
$ curl https://my-app.qeda.app/healthIf your application responds as expected, your new version is online.
Why use Qeda Push?
The main benefit is very simple: you can deploy more often without being afraid of taking your application offline. This is especially useful when you work on a SaaS product, an API, a web application, an internal tool, an application used by clients, or any project that receives regular updates. You can fix an issue in the morning and publish it quickly, then add a feature in the afternoon and deploy it without organizing a maintenance window — build, test, push, deploy, done.
What if you use Git?
Qeda Push integrates naturally into a Git-based development workflow. You can keep working the way you usually do — edit your code, test it, commit to Git, and Push to Qeda, and production follows — without a small team having to set up an entire DevOps pipeline before publishing a new version.
What about your URL?
Your public URL does not change just because you deploy a new version. If your application is accessible through https://my-app.qeda.app, your users keep using the same address — that subdomain is created automatically the first time you deploy, already served over SSL via Let's Encrypt, nothing to configure. And if you connected your own domain, such as https://myapp.com, you can keep using it the same way: the deployment concerns your application, not the address your users know.
A good habit before every Push
Even if Qeda simplifies deployment, always take a few seconds to check your new version before pushing:
- Test your change locally.
- Check the important features.
- Make sure your environment variables are correctly configured.
- Send your new version with Qeda Push.
- Test the application after deployment.
This gives you a simple and reliable workflow without adding unnecessary complexity.
Quick check
Once your Push is complete, you can check your application directly in the browser at https://my-app.qeda.app, test an endpoint with curl https://my-app.qeda.app/health, or simply open your own domain if you use one. The principle is always the same: deploy, verify, keep building.
Conclusion
Deploying a new version should not require warning your users every time you update your application. With Qeda Push, you can publish your changes with a simple workflow while keeping your application available during deployment.
You edit. You Push. Qeda handles the rest.