Kom i gang med SIAX Platform

Bestillingen starter på produktsiden. Du vælger konfiguration i konfiguratoren, ser prisen opdatere sig og afgiver ordren. Prisen genberegnes altid på serveren, før ordren oprettes, så beløbet i checkouten er det, der faktureres. Du behøver ikke en konto for at bestille — en e-mailadresse er nok, kontoen oprettes efter betalingen.

Efter betalingen får du to mails: en ordrebekræftelse med, hvad du har købt, og til hvilken pris, samt et login-link, der opretter kontoen. Linket er et engangslink med kort levetid. Er det udløbet eller aldrig kommet frem, så bed om et nyt fra login-siden, og tjek spammappen først — bekræftelsesmails havner der oftere, end man tror.

Når kontoen er oprettet, bliver det, du har bestilt, provisioneret. De fleste tjenester er oppe at køre, inden du er nået at udfylde faktureringsoplysningerne. Undtagelsen er dedikeret server: den gennemgås manuelt, fordi fysisk hardware skal allokeres, og du får i stedet for en færdig maskine besked med en planlagt overleveringsdato.

Alle priser på siden er ekskl. moms og angives som månedspris, medmindre andet er anført. Domæner faktureres pr. år.

• App Hosting: live på under et minut
• VPS: klar på 2–3 minutter
• Managed Postgres: klar på under et minut
• Objektlagring, backup og overvågning: med det samme
• Domæne, e-mail, git og CI, AI-gateway: minutter
• Dedikeret server: 1–3 arbejdsdage, manuel gennemgang

Gør dette, før du begynder at deploye, så du slipper for at rette det, når noget allerede er i produktion.

Sæt adgangskode og aktivér totrinsbekræftelse med det samme. Læg derefter faktureringsoplysninger ind: CVR-nummer, momsregistreringsnummer og en fakturaadresse, der går til økonomi og ikke til en personlig postkasse. Tilføj mindst én kollega med administratorrettighed — en konto, som kun én person kan tilgå, er en driftsrisiko, ikke en sikkerhedsforanstaltning.

Adskil miljøer fra starten. Opret projekter til henholdsvis produktion og test i stedet for at lægge alt i ét, og navngiv ressourcerne efter, hvad de gør. Det koster ikke noget at gøre det rigtigt nu, og det er besværligt at rede ud senere.

Vælg region bevidst. Vi kører i Helsinki, Falkenstein og Nürnberg. Latensen mellem app, database og lagring er lav inden for én region og mærkbar mellem to, så saml det, der taler sammen. At skifte region senere er ikke en indstilling — det er en ny ressource plus en datamigrering.

• Totrinsbekræftelse på alle konti med administratorrettighed
• To kontaktveje: én til fakturaer, én til driftsalarmer
• Egne projekter til produktion og test
• Samme region til app, database og lagring

Forbind en git-kilde først. SIAX Git (Gitea), GitHub og GitLab virker; forbindelsen laves enten med OAuth eller med en deploy-nøgle, hvis du hellere vil holde adgangen smal. Vælg derefter repo og branch. Den branch, du peger på, bliver produktionsbranchen — hvert push dertil bygger og deployer.

Findes der en Dockerfile i repoet, bruges den. Mangler den, forsøger byggetrinnet at genkende projektet automatisk. Automatisk genkendelse virker for almindelige Node-, Python- og Go-projekter, men en egen Dockerfile giver dig kontrol over byggetrinnet og er det, vi anbefaler til alt, der skal leve længere end en demo.

Læg miljøvariabler ind før den første deploy. Hemmeligheder kan skrives, men ikke læses tilbage i klartekst bagefter, så gem dem også selv. Appen skal lytte på 0.0.0.0 og på porten i miljøvariablen PORT — hårdkodet 3000 på localhost er den mest almindelige årsag til, at et build, der lykkes, alligevel ikke svarer. Sæt en health check-sti, så en defekt version ikke overtager trafikken.

Eget domæne peges ind med de værdier, konsollen viser. TLS-certifikatet udstedes automatisk, når DNS-posten peger rigtigt, hvilket kan tage nogle minutter. Sæt ikke en proxy eller CDN foran, før certifikatet er udstedt — så fejler valideringen. Pull requests får egne preview-miljøer, der ryddes op, når de merges, og rollback til en tidligere version er et enkelt klik.

• Byggeværktøjer i devDependencies skal installeres i byggetrinnet (npm ci --include=dev, eller en Dockerfile med flere trin)
• Lockfil skal være committet, ellers bliver bygget ikke reproducerbart
• Filsystemet er flygtigt: uploads og genererede filer skal ligge i objektlagringen
• Baggrundsjobs og køer kører som egen tjeneste, ikke i samme proces som webserveren
• Bygget kan kræve mere hukommelse end driften — størrelsen kan ændres bagefter

Læg din offentlige SSH-nøgle op i konsollen, før du opretter maskinen, helst en ed25519-nøgle. Login med adgangskode er slået fra fra start, så nøglen er eneste vej ind. Opretter du maskinen uden nøgle, må du gå via konsoladgangen for at lægge den ind bagefter.

Det første login er ssh root@IP-adressen, som står i konsollen. Lav derefter grundarbejdet med det samme: opdater pakkerne, opret en bruger med sudo, luk for root-login over SSH, slå automatiske sikkerhedsopdateringer til, og sæt firewallen. Åbn kun de porte, du faktisk bruger. Låser du dig selv ude med firewallreglen, findes konsoladgangen stadig — den går ikke via SSH.

VPS er en maskine med root, ikke en managed platform. Snapshots er inkluderet, men skemalagt backup er et tilvalg, du vælger ved bestilling (daglig med syv dages historik, eller hver time med tredive dage). Vælger du ingen backup, er det dig, der står for den. Går du videre med at sende e-mail fra maskinen, skal du også sætte reverse DNS på IP-adressen.

Dedikeret server fungerer anderledes: vi installerer og patcher operativsystemet, overvåger maskinen og kører backup med verificeret gendannelse. Du får adgangsoplysninger ved overleveringen, 1–3 arbejdsdage efter bestilling.

• ssh-keygen -t ed25519, læg den offentlige del op i konsollen før provisionering
• apt update && apt full-upgrade, derefter en ikke-root-bruger med sudo
• PermitRootLogin no og PasswordAuthentication no i sshd_config
• Firewall med kun de porte, tjenesten har brug for
• Konsoladgang i browseren, når SSH ikke virker

Konsollen giver dig host, port, databasenavn, bruger og adgangskode samt en færdig connection string på formen postgres://bruger:adgangskode@host:5432/database?sslmode=require. TLS er obligatorisk; en klient, der klager over certifikatet, er som regel en klient med et forældet CA-pakke. Databasen når dine andre SIAX-ressourcer uden at blive eksponeret offentligt — åbn den kun mod internettet, hvis du virkelig har brug for det, og begræns i så fald til kendte adresser.

Du får to connection strings: en poolet og en direkte. Brug den poolede til apps, der åbner mange korte forbindelser, og den direkte til migreringer, skemaændringer, pg_dump og pg_restore. Sessionsafhængige ting som prepared statements og LISTEN/NOTIFY hører hjemme på den direkte.

For at flytte data ind: tag en dump med pg_dump -Fc fra kilden, og indlæs med pg_restore --no-owner --no-privileges -j4 mod den nye database. Brug klientværktøjer, der matcher Postgres 17, ellers klager dumpen over formatversion. Kontrollér, hvilke extensions du bruger, før du begynder — almindelige extensions findes, men bygger din applikation på en extension, vi ikke kører, skal det redes ud før migreringen, ikke under.

Vær realistisk om nedetiden. Dump og gendannelse betyder, at skrivninger skal stoppes undervejs: nogle få gigabyte tager minutter, hundredvis af gigabyte tager timer, og indekser genopbygges efter gendannelsen. Vil du ned mod nul nedetid, kræver det logisk replikering med en planlagt omstilling, hvilket er et selvstændigt stykke arbejde og ikke noget, der klares på en eftermiddag. Ting, der ikke følger med i en dump — leverandørspecifik auth, row-level-policyer knyttet til en platforms egen brugertabel, serverløse autoskaleringsindstillinger, parametergrupper — skal bygges om.

• pg_dump -Fc -d kilde -f dump.pgc
• pg_restore --no-owner --no-privileges -j4 -d målstrengen dump.pgc
• Kør ANALYZE efter gendannelse, før du lukker trafik på
• Verificér rækkeantal pr. tabel mod kilden, før du skifter DNS eller connection string
• Point-in-time recovery findes, men test gendannelse på en kopi, før du får brug for den i skarp drift

Opret en bucket i konsollen, og generér derefter et adgangsnøglepar. Hemmeligheden vises én gang — læg den i din hemmelighedshåndtering med det samme. Endpoint-URL'en står ved siden af nøglerne og er den eneste indstilling ud over nøglerne, du skal ændre i eksisterende kode: API'et er S3-kompatibelt, så AWS SDK, boto3, aws-cli, rclone og s3cmd virker som de er.

To detaljer plejer at stoppe det første forsøg. Sæt path-style-adressering (forcePathStyle i SDK'erne) i stedet for virtual-host-style. Og udfyld region-feltet, selv om det ikke betyder noget hos os — flere SDK'er nægter at starte uden en værdi. Verificér med aws s3 ls --endpoint-url=... før du fejlsøger i applikationen. Flytter du data ind fra S3 eller Blob Storage, er rclone copy med tjeksummer det enkle valg; regn med, at offentlige buckets skal erstattes af signerede URL'er, da ACL-modellerne ikke er identiske. Udgående trafik op til tre gange den lagrede mængde er inkluderet.

Backupproduktet er almindelig restic mod en rest-server-endpoint, der er din egen. Initialisér repoet med restic -r rest:https://... init, angiv en repo-adgangskode, og gem den et andet sted end på den maskine, der sikkerhedskopieres. Krypteringen sker på din side, før data forlader maskinen, hvilket også betyder, at en mistet repo-adgangskode gør backuppen ulæselig — vi kan ikke genskabe den, og det er hele pointen med konstruktionen.

Skemalæg jobbet med systemd timer eller cron, kør restic forget --prune efter din udtyndingspolitik, og kør restic check jævnligt. Gendannelsesøvelsen køres efter skema fra vores side og logges med dato, så du har dokumentation for, at gendannelsen virkede, og ikke bare at jobbet startede.

• restic -r rest:https://endpoint/repo init
• restic backup /sti --verbose, med adgangskoden i en fil, som kun root kan læse
• restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
• restic restore latest --target /tmp/test — lav den øvelse selv også, den første uge

E-mail virker ikke, før fire ting stemmer i DNS. Konsollen viser de nøjagtige værdier for dit domæne; formen ser sådan ud.

MX peger på den host, konsollen angiver, med prioritet 10, og gamle MX-poster skal væk — ikke blive liggende som reserve. SPF er en TXT-post på domænets rod, og der må kun være én: har du allerede andre afsendere (fakturasystem, nyhedsbrev), samler du dem i samme post. DKIM lægges som den post og selector, konsollen viser. DMARC er en TXT-post på _dmarc med en rapporteringsadresse.

Rækkefølgen betyder noget ved en flytning. Opret postkasserne, og lad migreringen fra Google Workspace eller Microsoft 365 synkronisere færdigt først — den er inkluderet i prisen, og vi gør det for dig. Sænk TTL på MX-posten til 300 sekunder et døgn før skiftet. Skift MX sidst. Regn med en periode, hvor breve lander begge steder, mens resolvere når at følge med; det er normalt og ikke en fejl.

En ærlig advarsel om leveringsevne: et domæne, der begynder at sende fra en ny infrastruktur, har ingen oparbejdet historik hos modtagende udbydere. Kør DMARC med p=none i et par uger, læs rapporterne, og skærp derefter til p=quarantine og siden p=reject. Send ikke en stor udsendelse den første dag — så bygger du en dårlig start, som tager uger at arbejde væk igen. Ligger DNS hos en anden udbyder, går det udmærket, men så er propagering og ændringer deres domæne, ikke vores.

For at flytte et domæne hertil skal domænet være låst op hos den nuværende registrar, og du skal bruge auth-koden. En .se-overførsel tager normalt omkring fem dage. DNS kan håndteres i grænsefladen eller som kode med octoDNS, hvis du hellere versionsstyrer zonen.

• MX: værdien fra konsollen, prioritet 10, gamle poster fjernet
• SPF: én enkelt TXT-post på roden, alle legitime afsendere inkluderet, afslut med -all
• DKIM: posten og selectoren som konsollen viser, pr. domæne
• DMARC: TXT på _dmarc, start med p=none og en rua-adresse, du rent faktisk læser
• TTL 300 før skiftet, tilbage til normalværdi bagefter

Git-importen tager historik, issues og pull requests med. Du angiver repo-URL og en adgangstoken til kilden, og kan vælge spejling, hvis du vil lade det gamle sted blive liggende som en læsekopi under overgangen. Byggeminutter måles ikke — CI kører på din plan. Efter skiftet opdaterer du fjernforbindelsen med git remote set-url og peger webhooks og driftsflows om.

Vær ærlig over for dig selv om CI-flytningen. Simple workflows køres, som de er, af act_runner, men trin, der kalder kildeplatformens eget API, marketplace-handlinger, der forudsætter den platform, og OIDC-federation mod tredjepart, skal skrives om. Regn med en halv til en hel dag for en normal pipeline, mere hvis den er bygget med mange færdige actions.

Overvågningen kommer du i gang med på nogle minutter: opsæt tjek mod dine URL'er, TCP-porte, certifikater og cron-jobs, forbind alarmer til e-mail, Slack, Telegram eller webhook, og slå en offentlig statusside til, hvis du vil vise kunder status. Ti tjek er gratis uden tidsbegrænsning og uden kortoplysninger.

AI-gatewayen eksponerer et OpenAI-kompatibelt API. Opret en virtuel nøgle pr. projekt, sæt et budgetloft, og peg base-URL'en om i din klient — koden behøver ellers ikke ændres. Leverandørnøglerne ligger i gatewayen, ikke i applikationen, hvilket også er pointen: du kan skifte model uden at røre koden og ser hvert kald i sporingsvisningen. Vil du holde trafikken inden for EU, styrer du den til modeller, der kører på vores egen flåde, men vær opmærksom på, at de åbne modeller ikke er ombyttelige med de største proprietære i alle opgaver — test mod din egen evaluering, før du skifter i produktion.

• Importér repo med token, kør spejling i overgangsperioden
• git remote set-url origin, opdater webhooks og deploy-nøgler
• Pakkeregister til npm og Docker er inkluderet — peg .npmrc og docker login om
• Overvågning: 10 tjek gratis, alarmer til Slack eller webhook
• AI-gateway: en virtuel nøgle og et budgetloft pr. projekt

Næsten alle henvendelser, vi får det første døgn, handler om den samme håndfuld ting, og de fleste kan løses med det samme. Før du skriver til os: kontrollér, at DNS faktisk peger derhen, du tror (dig +short), at appen lytter på 0.0.0.0 og den rigtige port, og at SDK'en har både region og path-style sat mod objektlagringen.

Har du brug for os, findes supportformularen i konsollen på hver ressource — en henvendelse derfra får automatisk oplyst, hvilken ressource det drejer sig om, hvilket sparer en runde spørgsmål. Du kan også svare direkte på ordrebekræftelsen. Svartider og forpligtelser står i SLA-vilkårene; vi angiver dem ikke her for at undgå to versioner af det samme løfte. Platformsforstyrrelser offentliggøres på statussiden, og til migreringer, der er større end en eftermiddags arbejde, kan du bestille hjælp som en opgave i stedet for at kæmpe selv.

En ting, du bør vide fra starten: SIAX har ikke ISO 27001, SOC 2 eller PCI-DSS. Det, vi har, er GDPR-efterlevelse med databehandleraftale, al data i EU, og en stack af open source, som du kan gennemgå og forlade. Kræver dit udbud et certifikat, er vi den forkerte leverandør i dag, og det er bedre, at du ved det før migreringen end bagefter.

• Ingen login-mail: tjek spammappen, bed om et nyt link — det gamle er et engangslink med kort levetid
• Certifikat udstedes ikke: DNS peger endnu ikke rigtigt, eller også står en proxy foran under valideringen
• 502 efter et vellykket build: appen lytter på localhost eller en hårdkodet port i stedet for PORT
• Postgres afviser forbindelse: sslmode mangler, eller også forsøger du at nå den udefra uden at have åbnet for det
• S3-kald fejler: region-feltet er tomt, eller virtual-host-style bruges i stedet for path-style
• E-mail havner i spam: SPF, DKIM og DMARC er på plads, men domænet mangler stadig afsendelseshistorik