Av Mattias Dehlin, daglig leder i Buildex
Slik er Buildex bygget — infrastruktur, sikkerhet og driftsmodell
Når du vurderer et nytt prosjektstyringssystem, kommer ett spørsmål alltid først: kan vi stole på at det fungerer? Her er hvordan Buildex faktisk er satt opp — tre servere i Oslo, sikkerhetskopi hver time med automatisk gjenopprettingstest, tofaktor, tilgangskontroll i databasen og offentlig statusside.
Når du vurderer et nytt prosjektstyringssystem, er det ett spørsmål som alltid kommer først: kan vi stole på at det fungerer i morgen, om et år, om fem år? Vi har bygget Buildex med dette spørsmålet som premiss. Her er hvordan plattformen faktisk er satt opp — med tall målt 21. september 2026.
Hvor dataene dine ligger
Buildex kjører på tre virtuelle servere hos ServeTheWorld i Oslo — til sammen 16 kjerner og rundt 40 GB RAM. Datasenteret er norskeid, ISO 27001-sertifisert og drives på 90–95 % vannkraft.
- •Applikasjonsserver (8 kjerner, 16 GB RAM) — Webapplikasjonen, fillagring (Nextcloud) og utrulling.
- •Databaseserver (4 kjerner, 8 GB RAM) — Selvhostet Supabase: PostgreSQL, autentisering og API.
- •Driftsserver (4 dedikerte kjerner, 16 GB RAM, NVMe) — Konvertering av IFC- og DWG-filer, dokumentredigering, overvåking, feillogging og mottak av sikkerhetskopier.
Applikasjon og database står på hver sin server. Det er en bevisst sikkerhetsbeslutning: en sårbarhet i det ene laget gir ikke automatisk tilgang til det andre. Også tunge jobber som konvertering av IFC-modeller og DWG-tegninger skjer på vår egen server i Oslo — ingen fil sendes til en tredjepart for behandling.
Hvorfor det betyr noe: ansattlister, timer, HMS-hendelser, kontrakter og personopplysninger forblir i Norge, under norsk jurisdiksjon. Mange av de største konkurrentene bruker AWS, Azure eller GCP i EU — noe som åpner for amerikansk lov (CLOUD Act) selv når dataene fysisk ligger i Europa.
Sikkerhetskopiering i fire lag
- •Hver time: database, filer og konfigurasjon kopieres over kryptert forbindelse til en egen backupserver i Oslo, og en kopi blir liggende på kildeserveren for rask gjenoppretting.
- •Hver uke: den nyeste databasekopien gjenopprettes automatisk i et isolert miljø og kontrolleres mot radtall.
- •Hver dag: kryptert kopi av hele maskinen for applikasjons- og databaseserveren (Acronis hos STW), med daglig, ukentlig og månedlig rullering.
- •Hver uke: kryptert (AES-256) kopi til en frakoblet disk i Norge, verifisert med sjekksummer — den kopien som overlever at leverandøren selv er borte.
Alle kopiene ligger i Norge. Gjenoppretting skjer til nærmeste hele time. At en sikkerhetskopi finnes, beviser ingenting — derfor gjenoppretter vi den faktisk hver uke og sjekker at dataene er der.
Sikkerhet på applikasjonsnivå
- •Tilgangskontroll i selve databasen. Alle 426 tabeller har Row Level Security slått på, styrt av 1 146 regler som avgjør hvem som ser hva, helt ned på radnivå. En feil i applikasjonskoden kan ikke alene gi en bruker tilgang til en annen bedrifts data.
- •Sikker innlogging. Tofaktor (TOTP med autentikatorapp) kan slås på per konto. Kontoer med tofaktor må oppgi engangskode ved innlogging, og plattformens administratorkontoer må bruke tofaktor.
- •Roller per prosjekt, ikke bare per bedrift. Bedriftsadmin, prosjektleder/HMS-ansvarlig, intern ansatt, underentreprenør (admin og ansatt) og byggherre har hver sine rettigheter — og en bedrift kan være hovedbedrift på ett prosjekt og underentreprenør på et annet. Underentreprenører har alltid gratis tilgang, men ser kun det de skal se.
- •Revisjonslogg av innlogging og administrative handlinger som impersonering, brukeropprettelse og rolleendringer, oppbevart i 24 måneder.
- •Låste registreringer. RUH, observasjoner og HMS-avvik kan ikke endres i ettertid — historikken er det den var.
- •Kryptering der det teller mest. All trafikk går kryptert, og særlig sensitive felt — som fødselsnummer i eksponeringsregisteret og nøkler til regnskapsintegrasjoner — krypteres i databasen.
- •Validering av alle data som kommer inn gjennom API-et.
Drift og overvåkning
- •Offentlig statusside på status.buildex.no, overvåket fra utsiden av vårt eget datasenter — den varsler også når hele STW er nede.
- •Helsesjekk som kontrollerer database og alle planlagte jobber, ikke bare at nettsiden svarer.
- •Kontinuerlig feilovervåking med GlitchTip: alle feil som logges gås gjennom og rettes samme dag.
- •Uptime Kuma for oppetid, på egen driftsserver i Oslo sammen med feilloggingen.
- •Umami for webstatistikk — ingen cookies, ingen tredjepartssporing.
Stopper en planlagt jobb — en påminnelse, en synk mot regnskapet, en sikkerhetskopi — slår helsesjekken ut, og vi får varsel i løpet av minutter. Det er ikke nok å vite at nettsiden svarer; vi må vite at alt bak den faktisk går.
Hvordan vi vet at det fungerer
- •Til sammen over 15 000 automatiserte tester — 14 239 for webplattformen, 697 for mobilappen og 458 ende-til-ende-tester som klikker seg gjennom systemet slik en bruker gjør.
- •Hele testsuiten må passere før ny kode kan sendes til produksjon.
- •Røyktest mot produksjon etter hver utrulling.
- •Gjentatte sikkerhetsgjennomganger av hele kodebasen, med fokus på tilgangskontroll, dataeksponering mellom bedrifter og manipulering av forespørsler. Siste runde ble gjennomført i september 2026.
Når vi nærmer oss større virksomhetskunder, vil vi i tillegg bestille profesjonell penetrasjonstest fra en norsk spesialist, levert som tredjepartsverifisert rapport.
Regelverk
- •GDPR og personopplysningsloven — databehandleravtale inngås som del av kundeavtalen.
- •EU Cyber Resilience Act (CRA) — Buildex behandles som produsent etter CRA, med rutiner for sårbarhetsrapportering. Rapporteringsplikten gjelder fra 11. september 2026, og full anvendelse fra 11. desember 2027.
- •Koordinert sårbarhetsrapportering til support@buildex.no, publisert i /.well-known/security.txt.
Full teknisk og juridisk dokumentasjon finnes på sikkerhet og personvern.
Verifiser oss selv
- •Org.nr. 937 691 599 (Buildex AS) registrert i Brønnøysundregistrene.
- •Daglig leder med 25 års erfaring fra norsk bygg- og anleggsbransje.
- •Driftsstatus er åpent tilgjengelig på status.buildex.no.
- •Norsk datasenter, norsk selskap, norsk jurisdiksjon.
Vi er nye — det er en reell vurdering
Buildex ble lansert i april 2026, og har vært i daglig drift hos betalende kunder siden mai. Det er en reell ting å vurdere. Men «ny» betyr ikke «uprøvd arkitektur» — det betyr moderne arkitektur, bygget med dagens standarder fra dag én, uten teknisk gjeld fra 2010-tallet. Les mer i hvorfor velge et nytt system fremfor et etablert, eller snakk med oss direkte på kontakt@buildex.no eller via kontaktskjemaet.
Ofte stilte spørsmål
Hvor lagrer Buildex dataene?
På tre servere hos ServeTheWorld i Oslo — norskeid og ISO 27001-sertifisert, under norsk jurisdiksjon. Database, filer og konvertering av IFC- og DWG-filer skjer i samme datasenter, og alle sikkerhetskopier ligger i Norge.
Hvordan tar Buildex sikkerhetskopi?
Database, filer og konfigurasjon kopieres hver time til en egen backupserver i Oslo, og databasekopien gjenopprettes automatisk hver uke som test. I tillegg tas en daglig kryptert kopi av hele maskinen, og en ukentlig kryptert kopi til en frakoblet disk i Norge.
Støtter Buildex tofaktor-innlogging?
Ja. Tofaktor med autentikatorapp kan slås på per konto, og kontoer med tofaktor må oppgi engangskode ved innlogging. Plattformens administratorkontoer må bruke tofaktor.
Kan en underentreprenør se data fra andre bedrifter på prosjektet?
Nei. Tilgangen håndheves i selve databasen med Row Level Security på alle tabeller, og rollen avgjøres per prosjekt. Underentreprenører ser bare det som gjelder eget firma og fag.