You do three things to an application for as long as it lives: put it up, change it, and make the change real. Each one is a single command here — and the third one costs no downtime at all.
$ ringserv deploy ./myapp
Your code is copied into a named place, and your data gets a private corner beside it.
$ ringserv redeploy myapp
New code replaces old code. Your data stays. If it is running, the change goes live immediately.
$ ringserv reload
The running server picks up your edited file. No restart, and nobody using it notices.
This is the part worth understanding, because it is the mistake that hurts most and it is impossible here. A deployment keeps your database and your records in a separate folder — and a redeploy replaces everything except that folder.
So your data is not somewhere a redeploy is careful to avoid. It is somewhere a redeploy cannot go. There is no setting to get wrong and no order to remember — which matters most at the exact moment you are least careful.
Edit your file, run ringserv reload, and the server that
is already running is now running your new code. It does not restart. It does not let
go of its address. People using it right then keep using it.
On our machine that takes 62 milliseconds — and we check that a connection opened before the change is still working after it, because "it reloaded" and "it quietly restarted" look the same from outside.
| All good | every part of the server took your new code. |
| Refused | your code has an error, so nothing changed. The server is untouched and still serving. Fix it and try again. |
| Half done | rare, and the one worth restarting for — some of the server changed and some did not. |
Those three are worded differently on purpose. Someone who cannot tell nothing happened from half of it happened will react to both the same way, and only one of them is an emergency.
All three of these are buttons in the admin panel too, beside every application you have deployed — and the Reload button tells you which of the three things above happened. See the panel.
RingServ puts an application up on the machine you are on. It is not a supervisor, it does not run a cluster, and it will not deploy from another machine across the network. Each of those is a real need and a different product, and a server that grows one grows its problems too.
To keep an application running after a reboot, use what your system already has: a scheduled task on Windows, a service file on Linux. To reach it from the internet, put a proxy in front — which is also how it gets HTTPS (the Q&A explains why).
The full guide has every command, every option, and four things worth doing that we learned by running a real one.