Expertiză · Infrastructură și operare

Punem aplicația pe un server pe care îl controlăm, cu publicare reversibilă, copii de siguranță verificate și un loc unde se vede când ceva a căzut.

Găzduire, punere în funcțiune, monitorizare și continuitate pentru aplicații web și platforme cu bază de date. Lucrăm pe infrastructură pe care clientul o poate revendica: mașini virtuale la furnizori europeni, nginx, procese sub supraveghere, containere, bază de date autogăzduită. Include răspunsul la întrebarea „unde stau efectiv datele mele”.

Discută un proiect

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.

Ce cuprinde

Lucrarea, pe componente

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.

Cum arată

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ă.

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.

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.

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.

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.

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

Ce atingem, unde stau și cât rămân

Întrebările pe care le pune oricine are un responsabil cu protecția datelor — puse aici înainte să le pună el.

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.

Un caz

Un raport zilnic care nu mai rula de unsprezece zile, într-un sistem în care totul răspundea 200

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

Ce ne întreabă oamenii înainte să sune

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ă fiecare afirmație de mai sus (30 surse)

Site-ul rulează cu nginx și Next.js 16 pe OVHcloud București; procesul e supravegheat de PM2 cu repornire la depășirea memoriei, pauză între reporniri, număr maxim de reporniri și durată minimă de funcționareecosystem.config.js:3-26
Versiunea Next.js este ^16.1.1, React fixat la 19.1.0package.json:59, 63, 65
Aplicația se leagă la interfața locală pentru a fi accesibilă numai prin nginx, niciodată direct din internetecosystem.config.cjs:11-16
HSTS cu durată de un an, includerea subdomeniilor și preîncărcare; HTTP/2 activ; nginx 1.26.3; certificat gestionat de certbotnginx-ongdpr.md.conf:65, 251, 256-257
Sub HTTP/2 limita de conexiuni numără fluxurile: la o valoare mică o singură încărcare de pagină își respinge propriile fonturi și scripturi cu 429; valoarea a fost ridicată deliberatnginx-ongdpr.md.conf:49-61
Limitele de rată se aplică pe tip de trafic, nu global, cu vârf permis și fără întârzierenginx-ongdpr.md.conf:88, 112, 133
Configurația din depozit fusese divergentă față de producție, unde un fișier editat direct lăsase o copie de rezervă cu marcă de timp; divergența a fost citită înapoi de pe mașină și consemnatănginx-ongdpr.md.conf:12-20
Limitare de rată separată pentru API și pentru widget, upstream-uri cu prag de eșecuri și fereastră de excludere, corp maxim al cererii, timp de citire lung pentru conexiuni persistentenginx-aichat.conf:6-7, 11-19, 57, 72-84
Compresie cu prag minim de dimensiune și resurse statice cu expirare de un an și marcaj imutabilnginx.conf:14-18, 27-30
Publicare prin comutarea atomică a unei legături simbolice către versiunea curentă; unitatea systemd cu repornire la eșec, pauză scurtă, timp maxim de oprire și restricții de sistem (fără escaladare de privilegii, sistem de fișiere protejat, directoare personale inaccesibile, căi de scriere enumerate)sesizari-web.service:5-6, 31-50
Publicare prin sincronizare de director cu versiunea anterioară păstrată alături; verificarea extrage numele pachetului din pagina livrată și confirmă pe adresa publică; la eșec revine automat — mecanismul a anulat o publicare cu pachet vechi rămas în directorul runneruluideploy-web.sh:10-18, 27, 31-41
Acțiunile GitHub sunt fixate pe amprenta completă a commitului, cu motivul scris: î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; copia de lucru nu păstrează credențialeci.yml:30-36
Publicarea nu folosește tokenul platformei de cod, ci un runner propriu pe mașina țintă cu drepturi acordate punctual; fluxul rulează serializat, fără anularea execuției în cursdeploy.yml:15-22, 62, 86-89
Migrările de schemă nu sunt automatizate deliberat: se aplică manual, apoi se repornește componenta care își ține schema în memorie; fluxul construiește și copiază, atâtREADME.md:12, 58-59
Fișierul de mediu al producției nu trece prin platforma de cod: e copiat local pe mașină înainte de construire și șters imediat dupădeploy.yml:53-58
Copie de siguranță zilnică programată la oră fixă, cu recuperarea execuției ratate la următorul boot și întârziere aleatorie; export comprimat, iar un fișier gol e tratat ca eșec; fișierele din depozitul de obiecte se sincronizează separat; retenție locală configurabilăpg-backup.sh:4-16, 37-46
Programarea copiei: oră fixă zilnică, recuperare la boot, întârziere aleatoriesesizari-backup.timer:5-9
Copia în afara mașinii: cont de stocare într-o regiune nordică a UE, cu replicare geografică într-o a doua regiune din UE, acces public blocat, TLS minim 1.2, versionare și ștergere reversibilă 30 de zile, expirare automată 90 de zile, autentificare prin identitate gestionată — nicio cheie de stocare pe discRUNBOOK.md:1069
Sarcina de retenție depinde explicit de cea de copiere și rulează după ea; scrie un rând într-un tabel de execuții ca probă cerută de art. 5 alin. (2); nu recuperează execuțiile ratate; se rulează în gol cel puțin o săptămână înainte de prima activaresesizari-retention.service:3-7, 19-30
Un raport zilnic a fost mort unsprezece zile, cu declanșare corectă de fiecare dată; un cod 200 nu înseamnă o sarcină reușită, deci corpul răspunsului e parcurs după chei de eșec, cu alertă limitată în frecvențătaskin-run.sh:5-14, 26, 68, 76-107
Programarea a fost mutată din aplicație într-un planificator de sistem, pentru că un contor pornit în proces se resetează la fiecare repornire a serviciuluitaskin-loops.cron:3-5
Containere cu politică de repornire, verificări de sănătate (pregătirea bazei de date, punct de stare al aplicației), rotația jurnalelor la nivelul motorului de containere, porturi legate la interfața locală și variabile obligatorii care opresc pornirea dacă lipsescdocker-compose.yml:8, 18-29, 37-50, 88-111
Bază de date autogăzduită cu opt containere (bază, autentificare, REST, timp real, stocare, metadate, panou, poartă de acces), extensii activate explicit și parametri de memorie și conexiuni ajustați; migrarea a plecat de la o bază găzduită în Statele UniteSUPABASE-SELF-HOSTED-MIGRATION-50.md:4, 12, 28, 39, 42-43
Hardening de bază pe mașina virtuală: firewall care refuză implicit intrările și deschide doar SSH, HTTP și HTTPS; protecție împotriva încercărilor repetate; spațiu de swap; rotația jurnalelor motorului de containere; supraveghetorul de procese pornit la bootsetup-vm-baseline.sh:29-36, 71, 92, 96-106
Blocare împotriva ștergerii pe grupul de resurse al producțieiprovision-vm-aichat-prod.sh:96-97
Locațiile confirmate din mașină și din registrul adresei: OVHcloud București (RO) și Microsoft Azure Poland Central, ambele în SEEEXECUTIE.md:61
Jurnalele web se rotesc zilnic cu 14 exemplare păstrate, cu drepturi de citire restrânse la grupul de administrareregistru-prelucrari.md:74-76
Migrări versionate în depozite, numărate pe disc 06.09.2026: 559 pentru platforma vocală, 81 pentru boardul intern, 80 pentru CRM, 51 pentru platforma civică):numărate 06.09.2026
Publicarea acestui site se face manual: depozitul nu conține niciun flux de integrare continuăworkflows):verificat 06.09.2026
https://www.megapromoting.com răspunde 200 pe nginx + Next.jshttps://www.megapromoting.com/servicii · 2026-09-06

Citările interne arată numele fișierului și linia. Calea completă rămâne în depozitul nostru; o putem parcurge împreună, la cerere.

Cum lucrăm Toate serviciile

Ce ai vrea să funcționeze mai bine?

Povestește-ne despre procesul tău. Împreună stabilim ce merită construit, ce putem conecta și cum verificăm rezultatul.

Hai să discutăm