Kom i gang med SIAX Platform

Bestillingen starter på produktsiden. Du velger konfigurasjon i konfiguratoren, ser prisen oppdateres og legger inn bestillingen. Prisen regnes alltid om på nytt på serveren før ordren opprettes, så beløpet i checkouten er det som faktureres. Du trenger ingen konto for å bestille — det holder med en e-postadresse, kontoen opprettes etter betalingen.

Etter betalingen får du to e-poster: en ordrebekreftelse med hva du har kjøpt og til hvilken pris, og en innloggingslenke som oppretter kontoen. Lenken er en engangslenke med kort levetid. Har den gått ut eller aldri kommet frem, ber du om en ny fra innloggingssiden — og sjekk søppelposten først, bekreftelses-e-poster havner der oftere enn man tror.

Når kontoen er opprettet, blir det du har bestilt provisjonert. De fleste tjenester er i gang før du har rukket å fylle inn faktureringsopplysningene. Unntaket er dedikert server: den gjennomgås manuelt siden fysisk maskinvare skal allokeres, og du får en beskjed med planlagt overleveringsdato i stedet for en ferdig maskin.

Alle priser på nettstedet er eksklusive mva og oppgis som månedspris med mindre noe annet er angitt. Domener faktureres per år.

• App Hosting: live på under ett minutt
• VPS: klar på 2–3 minutter
• Managed Postgres: klar på under ett minutt
• Objektlagring, backup og overvåking: umiddelbart
• Domene, e-post, git og CI, AI-gateway: minutter
• Dedikert server: 1–3 arbeidsdager, manuell gjennomgang

Gjør dette før du begynner å deploye, så slipper du å rette det opp når noe allerede er i produksjon.

Sett passord og aktiver tofaktor med en gang. Legg deretter inn faktureringsopplysninger: organisasjonsnummer, mva-registreringsnummer og en fakturaadresse som går til økonomi og ikke til en personlig e-postboks. Legg til minst én kollega med administratorrettighet — en konto bare én person når, er en driftsrisiko, ikke et sikkerhetstiltak.

Skill miljøene fra starten. Opprett egne prosjekter for produksjon og test i stedet for å legge alt i ett, og navngi ressursene etter hva de gjør. Det koster ingenting å gjøre riktig nå, og er tungvint å rydde opp i senere.

Velg region bevisst. Vi kjører i Helsingfors, Falkenstein og Nürnberg. Latensen mellom app, database og lagring er lav innenfor én region og merkbar mellom to, så legg det som snakker sammen på samme sted. Å bytte region senere er ikke en innstilling — det er en ny ressurs pluss en datamigrering.

• Tofaktor på alle kontoer med administratorrettighet
• To kontaktveier: én for fakturaer, én for driftsalarmer
• Egne prosjekter for produksjon og test
• Samme region for app, database og lagring

Koble til en git-kilde først. SIAX Git (Gitea), GitHub og GitLab fungerer; koblingen gjøres enten med OAuth eller med en deploy-nøkkel hvis du heller vil holde tilgangen smal. Velg deretter repo og gren. Grenen du peker ut blir produksjonsgrenen — hver push dit bygger og deployer.

Finnes det en Dockerfile i repoet, brukes den. Mangler den, forsøker byggsteget å kjenne igjen prosjektet automatisk. Automatisk gjenkjenning fungerer for vanlige Node-, Python- og Go-prosjekter, men en egen Dockerfile gir deg kontroll over byggsteget og er det vi anbefaler for alt som skal leve lenger enn en demo.

Legg inn miljøvariabler før første deploy. Hemmeligheter kan skrives, men ikke leses tilbake i klartekst etterpå, så ta vare på dem hos deg selv også. Appen må lytte på 0.0.0.0 og på porten i miljøvariabelen PORT — hardkodet 3000 på localhost er den vanligste årsaken til at et vellykket bygg likevel ikke svarer. Sett en helsesjekk-sti slik at en ødelagt versjon ikke overtar trafikken.

Eget domene pekes inn med verdiene konsollen viser. TLS-sertifikatet utstedes automatisk når DNS-oppføringen peker riktig, noe som kan ta noen minutter. Ikke sett en proxy eller CDN foran før sertifikatet er utstedt — da mislykkes valideringen. Pull requests får egne forhåndsvisningsmiljøer som ryddes opp når de merges, og rollback til en tidligere versjon er ett klikk.

• Byggverktøy i devDependencies må installeres i byggsteget (npm ci --include=dev, eller en flertrinns-Dockerfile)
• Lockfil må være committet, ellers blir bygget ikke reproduserbart
• Filsystemet er flyktig: opplastinger og genererte filer skal til objektlagringen
• Bakgrunnsjobber og køer kjøres som egen tjeneste, ikke i samme prosess som webserveren
• Bygget kan trenge mer minne enn driften — størrelsen kan endres etterpå

Legg inn din offentlige SSH-nøkkel i konsollen før du oppretter maskinen, helst en ed25519-nøkkel. Passordinnlogging er avstengt fra start, så nøkkelen er eneste vei inn. Oppretter du maskinen uten nøkkel, må du gå via konsolltilgangen for å legge den inn etterpå.

Første innlogging er ssh root@IP-adressen som står i konsollen. Gjør deretter grunnarbeidet med en gang: oppdater pakkene, opprett en bruker med sudo, steng av root-innlogging over SSH, slå på automatiske sikkerhetsoppdateringer og sett opp brannmuren. Åpne bare portene du faktisk bruker. Låser du deg selv ute med brannmurregelen, finnes konsolltilgangen fortsatt — den går ikke via SSH.

VPS er en maskin med root, ikke en administrert plattform. Øyeblikksbilder er inkludert, men planlagt backup er et tilvalg du velger ved bestilling (daglig med syv dagers historikk, eller hver time med tretti dager). Velger du ingen backup, er det du som har ansvaret for den. Går du videre med e-postsending fra maskinen, må du også sette omvendt DNS på IP-adressen.

Dedikert server fungerer annerledes: vi installerer og patcher operativsystemet, overvåker maskinen og kjører backup med verifisert gjenoppretting. Du får tilgangsopplysninger ved overleveringen, 1–3 arbeidsdager etter bestilling.

• ssh-keygen -t ed25519, legg inn den offentlige delen i konsollen før provisjonering
• apt update && apt full-upgrade, deretter en ikke-root-bruker med sudo
• PermitRootLogin no og PasswordAuthentication no i sshd_config
• Brannmur med kun de portene tjenesten trenger
• Konsolltilgang i nettleseren når SSH ikke går gjennom

Konsollen gir deg vert, port, databasenavn, bruker og passord, samt en ferdig tilkoblingsstreng på formen postgres://bruker:passord@vert:5432/database?sslmode=require. TLS er obligatorisk; en klient som klager på sertifikatet, er som oftest en klient med gammel CA-pakke. Databasen når dine andre SIAX-ressurser uten å eksponeres offentlig — åpne den mot internett bare hvis du virkelig trenger det, og begrens i så fall til kjente adresser.

Du får to tilkoblingsstrenger: én poolet og én direkte. Bruk den poolede for apper som åpner mange korte tilkoblinger, og den direkte for migreringer, skjemaendringer, pg_dump og pg_restore. Sesjonsavhengige ting som prepared statements og LISTEN/NOTIFY hører hjemme på den direkte.

For å flytte inn data: ta en dump med pg_dump -Fc fra kilden og les inn med pg_restore --no-owner --no-privileges -j4 mot den nye databasen. Bruk klientverktøy som matcher Postgres 17, ellers klager dumpen på formatversjon. Kontroller hvilke utvidelser du bruker før du starter — vanlige utvidelser finnes, men bygger applikasjonen din på en utvidelse vi ikke kjører, må det ryddes opp i før migreringen, ikke underveis.

Vær realistisk om nedetiden. Dump og gjeninnlesing innebærer at skrivinger må stoppes i mellomtiden: noen gigabyte tar minutter, hundrevis av gigabyte tar timer, og indekser bygges om etter gjeninnlesingen. Vil du ned mot null nedetid, kreves logisk replikering med en planlagt overgang, noe som er et eget arbeid og ikke noe som ordnes på en ettermiddag. Ting som ikke følger med i en dump — leverandørspesifikk auth, radnivåpolicyer knyttet til en plattforms egen brukertabell, serverløse autoskaleringsinnstillinger, parametergrupper — må bygges om.

• pg_dump -Fc -d kilde -f dump.pgc
• pg_restore --no-owner --no-privileges -j4 -d målstrengen dump.pgc
• Kjør ANALYZE etter gjeninnlesing før du slipper på trafikk
• Verifiser radantall per tabell mot kilden før du bytter DNS eller tilkoblingsstreng
• Point-in-time recovery finnes, men test gjenoppretting på en kopi før du trenger den skarpt

Opprett en bucket i konsollen og generer deretter et tilgangsnøkkelpar. Hemmeligheten vises én gang — legg den i din hemmelighetshåndtering med en gang. Endpoint-URL-en står ved siden av nøklene og er den eneste innstillingen utover nøklene du trenger å endre i eksisterende kode: API-et er S3-kompatibelt, så AWS SDK, boto3, aws-cli, rclone og s3cmd fungerer som de er.

To detaljer pleier å stoppe det første forsøket. Sett path-style-adressering (forcePathStyle i SDK-ene) i stedet for virtual-host-style. Og fyll ut region-feltet selv om det ikke betyr noe hos oss — flere SDK-er nekter å starte uten verdi. Verifiser med aws s3 ls --endpoint-url=... før du feilsøker i applikasjonen. Flytter du inn data fra S3 eller Blob Storage, er rclone copy med sjekksummer det enkle valget; regn med at offentlige buckets må erstattes med signerte URL-er, siden ACL-modellene ikke er identiske. Utgående trafikk opp til tre ganger lagret volum er inkludert.

Backup-produktet er vanlig restic mot en rest-server-endpoint som er din egen. Initialiser repoet med restic -r rest:https://... init, angi et repopassord og lagre det et annet sted enn på maskinen som sikkerhetskopieres. Krypteringen skjer på din side før data forlater maskinen, noe som også betyr at et tapt repopassord gjør backupen uleselig — vi kan ikke gjenskape den, og det er hele poenget med konstruksjonen.

Planlegg jobben med systemd timer eller cron, kjør restic forget --prune etter din utrenskingspolicy og restic check jevnlig. Gjenopprettingsøvelsen kjøres etter en fast plan fra vår side og logges med dato, slik at du har dokumentasjon på at gjenopprettingen fungerte, og ikke bare at jobben startet.

• restic -r rest:https://endpoint/repo init
• restic backup /sti --verbose, med passordet i en fil bare root kan lese
• restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
• restic restore latest --target /tmp/test — gjør den øvelsen selv også, den første uken

E-post fungerer ikke før fire ting stemmer i DNS. Konsollen viser de eksakte verdiene for domenet ditt; formen ser slik ut.

MX peker på verten konsollen angir, med prioritet 10, og gamle MX-oppføringer skal bort — ikke ligge igjen som reserve. SPF er en TXT-oppføring på domenets rot, og det kan bare finnes én: har du allerede andre avsendere (fakturasystem, nyhetsbrev) slår du dem sammen i samme oppføring. DKIM legges inn som oppføringen og selektoren konsollen viser. DMARC er en TXT-oppføring på _dmarc med rapportadresse.

Rekkefølgen har betydning ved en flytting. Opprett postboksene og la migreringen fra Google Workspace eller Microsoft 365 synkronisere ferdig først — den er inkludert i prisen, og vi gjør den for deg. Senk TTL på MX-oppføringen til 300 sekunder ett døgn før overgangen. Bytt MX sist. Regn med en periode der e-post lander begge steder mens resolvere henter seg inn; det er normalt og ikke en feil.

En ærlig advarsel om leveringsdyktighet: et domene som begynner å sende fra ny infrastruktur, har ingen opparbeidet historikk hos mottakende operatører. Kjør DMARC med p=none i et par uker, les rapportene, og skjerp deretter til p=quarantine og deretter p=reject. Ikke send en stor utsendelse den første dagen — da bygger du en dårlig start som tar uker å arbeide bort. Ligger DNS hos en annen leverandør går det utmerket, men da er propagering og endringer deres ansvar, ikke vårt.

For domeneflytting hit må domenet være låst opp hos nåværende registrar, og du trenger auth-koden. En .se-overføring tar normalt rundt fem dager. DNS kan håndteres i grensesnittet eller som kode med octoDNS hvis du heller vil versjonsstyre sonen.

• MX: verdien fra konsollen, prioritet 10, gamle oppføringer fjernet
• SPF: én eneste TXT-oppføring på roten, alle legitime avsendere inkludert, avslutt med -all
• DKIM: oppføringen og selektoren konsollen viser, per domene
• DMARC: TXT på _dmarc, start med p=none og en rua-adresse du faktisk leser
• TTL 300 før overgangen, tilbake til normalverdi etterpå

Git-importen tar med historikk, issues og pull requests. Du oppgir repo-URL og en tilgangstoken til kilden, og kan velge speiling hvis du vil la det gamle stedet ligge igjen som lesekopi under overgangen. Byggminuttene måles ikke — CI kjøres på planen din. Etter overgangen oppdaterer du fjernkoblingen med git remote set-url og peker om webhooks og driftsflyter.

Vær ærlig med deg selv om CI-flyttingen. Enkle arbeidsflyter kjøres som de er av act_runner, men steg som kaller kildeplattformens eget API, markedsplasshandlinger som forutsetter den plattformen, og OIDC-føderasjon mot tredjepart må skrives om. Regn med en halv til en dag for en normal pipeline, mer hvis den er bygget med mange ferdige handlinger.

Overvåkingen kommer du i gang med på noen minutter: legg opp kontroller mot URL-ene, TCP-portene, sertifikatene og cron-jobbene dine, koble alarmer til e-post, Slack, Telegram eller webhook, og slå på en offentlig statusside hvis du vil vise kundene status. Ti kontroller er gratis uten tidsgrense og uten kortopplysninger.

AI-gatewayen eksponerer et OpenAI-kompatibelt API. Opprett en virtuell nøkkel per prosjekt, sett budsjettak, og pek om base-URL-en i klienten din — koden trenger for øvrig ikke endres. Leverandørnøklene ligger i gatewayen, ikke i applikasjonen, noe som også er poenget: du kan bytte modell uten å røre koden, og ser hvert kall i sporingsvisningen. Vil du holde trafikken innenfor EU, styrer du den til modeller som kjøres på vår egen flåte, men vær klar over at de åpne modellene ikke er utbyttbare mot de største proprietære i alle oppgaver — test mot din egen evaluering før du bytter i produksjon.

• Importer repo med token, kjør speiling i overgangsperioden
• git remote set-url origin, oppdater webhooks og deploy-nøkler
• Pakkeregister for npm og Docker er inkludert — pek om .npmrc og docker login
• Overvåking: 10 kontroller gratis, alarm til Slack eller webhook
• AI-gateway: én virtuell nøkkel og ett budsjettak per prosjekt

Nesten alle sakene vi får det første døgnet, handler om den samme håndfullen ting, og de fleste kan løses med en gang. Før du skriver til oss: kontroller at DNS faktisk peker dit du tror (dig +short), at appen lytter på 0.0.0.0 og riktig port, og at SDK-en har både region og path-style satt mot objektlagringen.

Trenger du oss, finnes supportskjemaet i konsollen på hver ressurs — en sak derfra får automatisk med hvilken ressurs det gjelder, noe som sparer en runde med spørsmål. Du kan også svare direkte på ordrebekreftelsen. Svartider og forpliktelser står i SLA-vilkårene; vi oppgir dem ikke her for å slippe to versjoner av samme løfte. Plattformforstyrrelser publiseres på statussiden, og for migreringer som er større enn en ettermiddags arbeid, kan du bestille hjelp som oppdrag i stedet for å kjempe alene.

Én ting du bør vite fra start: SIAX har ikke ISO 27001, SOC 2 eller PCI-DSS. Det vi har, er GDPR-etterlevelse med databehandleravtale, all data i EU, og en stack av åpen kildekode som du kan gjennomgå og ta med deg videre. Krever anskaffelsen deres et sertifikat, er vi feil leverandør i dag, og det er bedre at du vet det før migreringen enn etter.

• Ingen innloggings-e-post: sjekk søppelposten, be om ny lenke — den gamle er engangs og kortlevd
• Sertifikat utstedes ikke: DNS peker ikke riktig ennå, eller det står en proxy foran under valideringen
• 502 etter vellykket bygg: appen lytter på localhost eller hardkodet port i stedet for PORT
• Postgres nekter tilkobling: sslmode mangler, eller du prøver å nå den utenfra uten å ha åpnet for det
• S3-kall mislykkes: region-feltet tomt eller virtual-host-style i stedet for path-style
• E-post havner i søppelpost: SPF, DKIM og DMARC på plass, men domenet mangler ennå sendehistorikk