Hi Osvaldo,
thanks for the clear answer — that basically settles the server question:
Great, we have the server.
My simple follow-up question is:
What do we do about release anxiety?
I don’t mean this ironically.
This anxiety is well known in software engineering: it usually doesn’t come from bad code, but from uncertainty around going public — infrastructure, security, load, and failure cases.
This is where many beginners get stuck:
the server runs locally,
the application works,
but go-live still feels unsafe.
That’s why a simple, reproducible reference setup might help more than another feature post:
This is how we put HIX safely on the Internet — and go live.
One important part of this is GDPR:
even with a web firewall or tunnel, questions remain about TLS termination, data visibility, and end-to-end encryption.
A clearly documented standard setup would reduce uncertainty
and make go-live much easier, especially for newcomers.
Best regards,
Otto
PS:
For context: the release anxiety mentioned here is well supported by software-engineering research.
Multiple peer-reviewed studies show that developer stress and anxiety are driven primarily by unclear production, security, and infrastructure models, not by weak code.
Examples include:
Graziotin et al., On the Unhappiness of Software Developers (2017)
Suárez & VizcaĂno, Stress, Motivation, and Performance in Software Engineering
Godliauskas & Ĺ mite, The Well-Being of Software Engineers: A Systematic Literature Review
Kurian et al., Perceived Stress and Fatigue in Software Developers
These studies consistently conclude that
the more transparent and understandable go-live and security architectures are,
the lower the release anxiety — especially for beginners.