Wir bringen Ihre Anwendung auf einen Server, den wir kontrollieren, mit umkehrbarer Veröffentlichung, geprüften Backups und einer Stelle, an der sichtbar wird, wenn etwas ausgefallen ist.
Hosting, Inbetriebnahme, Monitoring und Kontinuität für Webanwendungen und datenbankgestützte Plattformen. Wir arbeiten mit Infrastruktur, die der Kunde für sich beanspruchen kann: virtuelle Maschinen bei europäischen Anbietern, nginx, überwachte Prozesse, Container, selbst gehostete Datenbank. Dazu gehört die Antwort auf die Frage „wo liegen meine Daten eigentlich tatsächlich“.
Construit dejaOperăm în acest fel mai multe sisteme proprii, iar configurațiile sunt în depozite, nu doar pe servere. Site-ul acesta rulează pe nginx cu Next.js 16 sub PM2, la OVHcloud București. Platforma de asistenți rulează pe Microsoft Azure, Poland Central, cu MySQL, Redis și RabbitMQ în containere legate la interfața locală. O platformă civică proprie folosește unități systemd cu publicare prin comutare atomică de legătură simbolică, copie de siguranță zilnică verificată și o sarcină separată de retenție care rulează numai dacă acea copie a reușit. Un board intern se publică prin runner propriu, cu acțiuni GitHub fixate pe amprentă completă și cu revenire automată la versiunea anterioară dacă verificarea de sănătate cade după publicare. Rezerva care trebuie spusă: gradul de automatizare diferă de la sistem la sistem. Publicarea acestui site se face încă manual, iar migrările de bază de date sunt aplicate cu mâna, deliberat. Nu vindem un lanț automat pe care nu îl avem peste tot.
O aplicație care merge pe laptop și una care merge în producție se deosebesc prin lucruri care nu se văd în interfață: ce se întâmplă când procesul moare la trei noaptea, ce se întâmplă când o publicare iese prost, unde ajung jurnalele, cine află primul că ceva a căzut și de unde se recuperează baza de date dacă discul dispare. Serviciul acesta se ocupă exact de partea aceea.
Alegerea de bază pe care o propunem este infrastructura pe care clientul o poate revendica: o mașină virtuală la un furnizor european, nginx în față, procese sub un supraveghetor, containere unde are sens, bază de date autogăzduită unde independența contează mai mult decât comoditatea. Nu pentru că platformele gestionate ar fi rele — ci pentru că într-o zi vrei să poți lua totul și pleca, iar dacă asta nu a fost gândit la început, nu se mai poate face ieftin.
Întrebarea despre suveranitatea datelor are un singur răspuns onest: unul verificat. Locația se confirmă interogând serviciul de metadate al mașinii virtuale și registrul adresei, nu citind pagina de marketing a furnizorului. Diferența nu e teoretică — pentru un transfer în interiorul Spațiului Economic European, capitolul de transferuri din Legea 195/2024 pur și simplu nu se aplică. O migrare făcută de noi a mutat o platformă de la o bază de date găzduită în Statele Unite pe o stivă autogăzduită în Uniunea Europeană, tocmai din acest motiv.
Ce nu promitem: că totul e automat. Migrările de schemă le aplicăm cu mâna, în mod deliberat, pentru că o migrare aplicată automat pe producție de un lanț care nu știe ce e în tabelă e felul obișnuit în care se pierd date. Publicarea codului se automatizează; schimbarea structurii bazei rămâne o decizie umană, cu copie de siguranță proaspătă în spate.
Was dazugehört
Die Arbeit, nach Bestandteilen
Publicare reversibilă, cu verificare după, nu doar înainte
Publicarea nu se termină când fișierele au ajuns pe server, ci când o cerere reală dovedește că versiunea nouă e cea servită. Într-una dintre implementări, scriptul sincronizează directorul, păstrează versiunea anterioară alături, apoi extrage numele pachetului din pagina livrată și verifică pe adresa publică dacă exact acel fișier se servește; dacă nu, revine singur la versiunea anterioară. Nu e teoretic: mecanismul a prins un pachet rămas vechi în directorul runnerului și a anulat o publicare care altfel ar fi părut reușită.
Comutare atomică de versiune, cu procesul sub systemd
Alternativa la „oprim, copiem peste, pornim” este directorul de versiuni plus o legătură simbolică comutată dintr-o singură operație. Unitatea systemd arată mereu spre calea stabilă, iar revenirea înseamnă comutarea legăturii înapoi. Unitatea are politică de repornire la eșec cu pauză scurtă, timp maxim de oprire, și restricții de sistem: fără escaladare de privilegii, sistem de fișiere protejat, directoare personale inaccesibile, cu o listă explicită de căi în care are voie să scrie.
nginx în față, cu limite scrise pentru cazul real
Terminare TLS cu reînnoire automată a certificatului, HSTS cu durată de un an și includerea subdomeniilor, compresie cu prag minim de dimensiune, resurse statice cu expirare lungă și marcaj imutabil, iar aplicația legată la interfața locală ca să nu poată fi atinsă direct din internet. Limitele de rată se stabilesc pe tipul de trafic, nu global. O lecție plătită merită spusă: sub HTTP/2, limita de conexiuni numără fluxurile, nu conexiunile — la o valoare mică, o singură încărcare de pagină își respinge singură fonturile și scripturile cu 429.
Copie de siguranță care se verifică, nu doar se rulează
Sarcină zilnică programată, cu pornire la următorul boot dacă mașina era oprită la ora respectivă și cu întârziere aleatorie ca să nu pornească totul în aceeași secundă. Exportul bazei se comprimă, iar dacă fișierul rezultat e gol, execuția se tratează ca eșec — un export care se termină „cu succes” și produce zero octeți este modul obișnuit în care se descoperă, peste șase luni, că nu există copie. Fișierele din depozitul de obiecte se sincronizează separat. O copie 100% locală nu supraviețuiește pierderii discului, deci copia se duce și în afara mașinii, într-un cont de stocare din Uniunea Europeană cu replicare geografică, versionare, ștergere reversibilă și expirare automată — cu acces prin identitate gestionată, ca să nu existe nicio cheie de stocare pe disc.
Ștergerea programată rulează numai după o copie reușită
Sarcina de retenție depinde explicit de cea de copiere și pornește după ea. O curățare fără copie proaspătă este singura formă de ștergere din care nu există întoarcere. Spre deosebire de copiere, ștergerea nu recuperează execuțiile ratate: dacă mașina a fost oprită, nu se șterge de două ori a doua zi. Fiecare rulare scrie un rând într-un tabel de execuții, iar înainte de prima activare reală sarcina rulează în gol cel puțin o săptămână și se citește jurnalul.
Alarme care nu mint și nu spamează
O sarcină programată care returnează 200 nu înseamnă o sarcină care a funcționat. Învelișul nostru de execuție citește corpul răspunsului și caută în el eșecurile parțiale, apoi trimite alertă cu limitare de frecvență, ca un serviciu căzut toată ziua să nu producă nouăzeci și șase de mesaje identice. Motivul pentru care există: un raport zilnic a fost mort unsprezece zile la rând, iar singura urmă era un gol într-un tabel pe care nu-l privea nimeni. Sarcina programată se declanșase de toate cele unsprezece ori.
Lanț de publicare care nu poate fi deturnat din amonte
Acțiunile din fluxul de integrare sunt fixate pe amprenta completă a commitului, nu pe etichetă. În martie 2026, o acțiune populară a fost re-direcționată de la etichetele `v1`…`v45` către cod malițios și a atins peste 23.000 de depozite în 24 de ore; o amprentă nu se mută. Fluxul nu păstrează credențiale în copia de lucru, iar publicarea nu trece printr-un token: merge printr-un runner propriu, pe mașina țintă, cu drepturi acordate punctual. Astfel nicio cheie de acces la server nu stă în platforma de cod.
Containere cu limite, verificări de sănătate și jurnale care nu umplu discul
Fiecare serviciu are politică de repornire, verificare de sănătate proprie (pregătirea bazei de date, un punct de stare al aplicației), limite de procesor și memorie unde încărcarea o cere, și rotația jurnalelor la nivelul motorului de containere, cu dimensiune maximă și număr de fișiere. Porturile bazelor de date se leagă la interfața locală, niciodată public. Variabilele obligatorii sunt declarate astfel încât containerul refuză să pornească dacă lipsesc, în loc să pornească cu o valoare implicită periculoasă.
Bază de date autogăzduită, când independența contează
Stivă completă în containere — bază de date, autentificare, interfață REST, canal în timp real, stocare de fișiere, poartă de acces — cu extensiile activate explicit și cu parametrii de memorie și de conexiuni potriviți mașinii, nu lăsați la valorile implicite. Migrările sunt fișiere versionate în depozit și se aplică manual, cu repornirea componentei care își ține schema în memorie. Motivul acestei alegeri e simplu: o platformă gestionată din afara Uniunii Europene poate fi excelentă tehnic și totuși nepotrivită juridic.
Wie es aussieht
Der Ablauf, Schritt für Schritt.
01
Inventariem ce există și ce se poate pierde
Ce rulează efectiv pe mașină, sub ce supraveghetor, cu ce versiuni, cu ce porturi expuse; ce copii de siguranță există și dacă vreuna a fost restaurată vreodată; ce secrete au ajuns în depozite; care este diferența dintre configurația din depozit și fișierul de pe server. Ultimul punct produce aproape întotdeauna surprize — noi înșine avem documentat un caz în care fișierul de pe server fusese editat direct, în afara depozitului, și a lăsat o copie de rezervă cu marcă de timp lângă el. Livrăm inventarul și lista punctelor unice de eșec.
02
Punem baza: server, nginx, procese, hardening
Firewall care refuză implicit intrările și deschide doar ce trebuie, protecție împotriva încercărilor repetate de autentificare, spațiu de swap dimensionat, nginx cu TLS și reînnoire automată, aplicația legată la interfața locală, supraveghetorul de procese configurat să pornească la boot. Livrăm configurațiile în depozit, nu doar pe mașină, ca următoarea persoană să nu le reconstruiască din memorie.
03
Facem publicarea repetabilă și reversibilă
Script de publicare cu versiunea anterioară păstrată, verificare de sănătate după publicare și revenire automată la eșec. Unde există echipă și integrare continuă, se adaugă runner propriu pe mașina țintă, cu acțiuni fixate pe amprentă și fără credențiale în copia de lucru. Livrăm procedura scrisă și o revenire executată în fața clientului — o revenire netestată nu este o revenire.
04
Punem copiile, retenția și alarmele
Copie zilnică cu verificarea că fișierul nu e gol, copie în afara mașinii într-o regiune din Uniunea Europeană, sarcina de retenție care rulează numai după o copie reușită și lasă urmă, plus alarme cu limitare de frecvență care citesc conținutul răspunsului, nu doar codul de stare. Livrăm o restaurare de probă făcută efectiv și jurnalul ei.
05
Predăm cheile și scriem ce rămâne nefăcut
Acces în cont propriu, documentația de operare, lista sarcinilor programate și — obligatoriu — lista onestă a lucrurilor care nu s-au automatizat și de ce. La noi, două rămân aproape mereu pe listă: migrările de schemă, aplicate cu mâna în mod deliberat, și publicarea acestui site, care e încă manuală.
Straturile unei instalări, de jos în sus: mașina virtuală într-o regiune europeană confirmată, motorul de containere cu rotația jurnalelor, baza de date cu copia zilnică verificată și copia din afara mașinii, procesele sub supraveghetor cu repornire la eșec, nginx cu TLS și limite de rată — iar lateral, lanțul de publicare cu versiunea anterioară păstrată și revenirea automată.
Datele
Was wir anfassen, wo die Daten liegen und wie lange sie bleiben
Die Fragen, die sich jeder stellt, der über einen Datenschutzbeauftragten verfügt — hier gestellt, bevor er selbst danach fragt.
Unde stau efectiv datele și cum se verifică
Locația se confirmă din mașină, nu din documentație: serviciul de metadate al furnizorului spune regiunea reală, iar registrul adresei spune țara. Sistemele noastre stau la OVHcloud, București, România și pe Microsoft Azure, Poland Central — ambele în Spațiul Economic European. Copiile de siguranță ale platformei civice stau într-o regiune nordică a Uniunii, cu replicare într-o a doua regiune tot din Uniune. Aceste rânduri au înlocuit o listă mai lungă de locații pe care nu le-am putut confirma.
Ce vedem noi în timpul lucrării
Configurație, jurnale, schema bazei și starea proceselor. Conținutul datelor personale nu face parte din lucrare; unde o depanare cere totuși un exemplu, se folosește un caz creat pentru asta. Accesul administrativ se acordă pe durata intervenției, nominal, și se retrage la final — iar retragerea se verifică, nu se presupune.
Jurnalele și cât trăiesc
Jurnalele web ale acestui site se rotesc zilnic, cu paisprezece exemplare păstrate, cu drepturi de citire restrânse la grupul de administrare. La nivel de containere, rotația se face de motorul de containere, cu dimensiune și număr de fișiere fixate, ca un serviciu vorbăreț să nu umple discul și să oprească baza de date — modul cel mai banal de a pica o producție.
Secretele nu stau în depozit
Valorile sensibile intră din fișiere de mediu cu drepturi restrânse, citite de unitatea de sistem, nu scrise în unitate — pentru că definiția unei unități și jurnalul de sistem sunt lizibile pentru mai mulți oameni decât se crede. În lanțul de publicare, fișierul de mediu al producției nu trece prin platforma de cod: e copiat local pe mașină și șters imediat după construire. Când preluăm o infrastructură existentă, prima trecere este întotdeauna un inventar al secretelor ajunse în depozite, cu plan de rotație.
Continuitatea: ce se întâmplă când plecăm
Predarea înseamnă acces în cont propriu la furnizorul de infrastructură, depozitul cu toate configurațiile de server, procedura de publicare și de revenire, cea de restaurare a copiei de siguranță — testată, nu doar scrisă — și lista sarcinilor programate cu ce face fiecare. Blocarea împotriva ștergerii accidentale se pune pe grupul de resurse al producției de la început.
Ein Fall
Ein täglicher Bericht, der seit elf Tagen nicht mehr lief, in einem System, in dem alles 200 antwortete
Situația
Într-o platformă internă proprie, mai multe rutine automate produc zilnic rapoarte și curăță date. Sarcinile erau pornite din interiorul aplicației, cu contoare în proces. Nimic nu semnala vreo problemă: serviciul era pornit, adresa răspundea, jurnalele nu conțineau erori.
Ce am construit
Raportul zilnic lipsea de unsprezece zile, iar singura urmă era un gol într-un tabel pe care nu-l privea nimeni. Au ieșit la iveală două defecte distincte. Primul: un contor pornit în interiorul aplicației se resetează la fiecare repornire a serviciului, deci o rutină cu interval mai lung decât intervalul dintre publicări nu se declanșează niciodată. Al doilea, mai insidios: rutina fusese declanșată corect de toate cele unsprezece ori și returnase de fiecare dată cod 200 — dar corpul răspunsului conținea eșecuri parțiale pe care nimeni nu le citea.
Ce a ieșit
Programarea a fost mutată în afara aplicației, într-un planificator de sistem căruia nu-i pasă de reporniri. Execuția a fost învelită într-un script care scrie o linie de jurnal per rulare, parcurge corpul răspunsului după chei de eșec și trimite alertă către un canal de mesagerie — cu limitare de frecvență, ca o dependență căzută toată ziua să nu producă nouăzeci și șase de mesaje identice. Un răspuns 200 cu eșecuri interne are acum stare proprie, distinctă de succes.
Ce nu spune cazul
Nimic din asta nu a fost o problemă de infrastructură în sensul clasic: serverul mergea, discul avea loc, procesul era viu. Exact de aceea a durat unsprezece zile. Cele mai scumpe defecte de operare nu sunt căderile — acelea se văd — ci lucrurile care raportează succes fără să facă nimic. Verificarea de sănătate care contează nu întreabă „ești pornit?”, ci „ai făcut ce trebuia, de câte ori trebuia?”.
Întrebări
Was uns die Leute fragen, bevor sie anrufen
Unde vor sta efectiv datele noastre?
Unde alegeți, și verificăm că e chiar acolo. Sistemele noastre stau la OVHcloud, București și pe Microsoft Azure, Poland Central, ambele în Spațiul Economic European, iar locația a fost confirmată interogând serviciul de metadate al mașinii virtuale și registrul adresei — nu citind documentația furnizorului. Verificarea contează: pentru un transfer în interiorul Spațiului Economic European, capitolul privind transferurile din Legea 195/2024 nu se aplică și nu sunt necesare autorizări speciale. În afara lui, apare un dosar de garanții.
De ce server propriu și nu o platformă gestionată?
Nu întotdeauna. O platformă gestionată e alegerea corectă când echipa e mică, traficul e neregulat și nimic din stivă nu are cerințe de rezidență. Serverul propriu devine argumentul mai bun în trei situații: când datele trebuie să rămână într-o jurisdicție anume, când costul devine imprevizibil la scară, și când vreți să puteți lua totul și pleca. Am făcut și migrarea inversă pentru un sistem propriu: de la o bază de date găzduită în Statele Unite la o stivă autogăzduită în Uniunea Europeană, cu opt containere — bază de date, autentificare, interfață REST, timp real, stocare, metadate, panou și poartă de acces.
Ce se întâmplă dacă o publicare iese prost?
Se revine, și de preferat singură. Versiunea anterioară rămâne pe disc lângă cea nouă, iar după publicare o verificare cere pagina reală și confirmă că fișierul servit e cel abia construit; dacă nu, scriptul revine automat. Unde folosim comutarea atomică de legătură simbolică, revenirea e o singură operație. Nu e o descriere de broșură — mecanismul a prins deja o publicare cu un pachet vechi rămas în directorul de lucru al runnerului și a anulat-o.
Faceți copii de siguranță? Cât de des și le testați?
Zilnic acolo unde am construit-o — și subliniem asta, pentru că o copie automată nu apare de la sine când muți o aplicație pe un server. Copia rulează la oră fixă, se recuperează la următorul boot dacă mașina era oprită, iar dacă exportul iese gol execuția e tratată ca eșec. Copia pleacă și în afara mașinii, într-o regiune din Uniunea Europeană, cu replicare, versionare, ștergere reversibilă și expirare automată. Testul de restaurare face parte din livrare: o copie nerestaurată niciodată e o presupunere, nu o copie.
Cine află primul când ceva cade?
Depinde ce am construit, și merită spus fără înflorituri. Verificările de sănătate la nivel de container și punctele de stare ale aplicațiilor există; alarma către un canal de mesagerie, cu limitare de frecvență, există acolo unde am construit-o. Un punct de verificare a stării pe care nu-l interoghează nimeni nu e monitorizare — e o pagină. Dacă vreți monitorizare adevărată, este o etapă separată, cu un observator extern care interoghează periodic și cu un destinatar al alertei care are voie să fie trezit.
Aplicați automat migrările bazei de date la fiecare publicare?
Nu, și este o decizie luată în cunoștință de cauză, nu o scăpare. Lanțul de publicare construiește și copiază codul; atât. Schimbările de schemă sunt fișiere versionate în depozit, aplicate manual, cu copie de siguranță proaspătă în spate, iar componentele care își țin schema în memorie se repornesc după. O migrare aplicată automat pe producție de un proces care nu știe ce e în tabelă e felul obișnuit în care se pierd date ireversibil.
Cum evitați ca lanțul vostru de publicare să devină o cale de atac?
Prin trei reguli. Acțiunile externe sunt fixate pe amprenta completă a commitului, nu pe etichetă — în martie 2026 o acțiune folosită pe scară largă a fost re-direcționată de la etichetele ei către cod malițios și a atins peste 23.000 de depozite în 24 de ore. Copia de lucru nu păstrează credențiale. Publicarea nu se face cu o cheie de acces stocată în platforma de cod, ci printr-un executant propriu care rulează pe mașina țintă, cu drepturi acordate punctual. Recunoaștem că nu toate proiectele noastre mai vechi respectă încă toate trei; migrarea lor e o lucrare în sine.
Preluați o infrastructură făcută de altcineva?
Da, și prima trecere e întotdeauna un inventar, nu o modificare. Ce rulează efectiv, sub ce supraveghetor, cu ce versiuni, ce porturi sunt expuse, ce copii de siguranță există, dacă vreuna a fost restaurată vreodată, ce secrete au ajuns în depozite și în ce măsură configurația din depozit mai seamănă cu fișierul de pe server. Ultima verificare produce aproape mereu ceva: avem documentat, într-un proiect propriu, un fișier de configurație editat direct pe producție, care a lăsat o copie de rezervă cu marcă de timp alături.
Ce se întâmplă dacă vrem să lucrăm cu altcineva?
Plecați cu totul. Infrastructura stă pe conturile voastre la furnizor de la început, iar predarea include depozitul cu toate configurațiile de server, procedura de publicare și de revenire, procedura de restaurare testată și lista sarcinilor programate cu ce face fiecare. Blocarea împotriva ștergerii accidentale a grupului de resurse de producție se pune de la instalare. Dacă un furnizor vă condiționează plecarea de rescrierea infrastructurii, asta era problema, nu tehnologia.
Pe ce se sprijină afirmațiile de mai sus (30 surse)
29 dintre ele sunt cod și fișiere din depozitele noastre. Nu le publicăm numele și nici linia: împreună, pe o singură pagină, ar descrie prea exact cum sunt construite sisteme care nu sunt doar ale noastre. Le parcurgem cu tine, în depozit, la cerere — verificarea rămâne posibilă, doar că se face într-o discuție.