Kom igång med SIAX Platform

Beställningen börjar på produktsidan. Du väljer konfiguration i konfiguratorn, ser priset uppdateras och lägger ordern. Priset räknas alltid om på servern innan ordern skapas, så beloppet i checkouten är det som faktureras. Du behöver inget konto för att beställa — det räcker med en e-postadress, kontot skapas efter betalningen.

Efter betalningen får du två mejl: en orderbekräftelse med vad du köpt och till vilket pris, och en inloggningslänk som skapar kontot. Länken är en engångslänk med kort livslängd. Har den gått ut eller aldrig kommit fram, begär en ny från inloggningssidan och titta i skräpposten först — bekräftelsemejl fastnar där oftare än man tror.

När kontot är skapat provisioneras det du beställt. De flesta tjänster är igång innan du hunnit fylla i faktureringsuppgifterna. Undantaget är dedikerad server: den granskas manuellt eftersom fysisk hårdvara ska allokeras, och du får ett besked med planerat överlämningsdatum i stället för en färdig maskin.

Alla priser på sajten är exklusive moms och anges som månadspris om inget annat står. Domäner faktureras per år.

• App Hosting: live på under en minut
• VPS: klar på 2–3 minuter
• Managed Postgres: klar på under en minut
• Objektlagring, backup och övervakning: direkt
• Domän, e-post, git och CI, AI-gateway: minuter
• Dedikerad server: 1–3 arbetsdagar, manuell granskning

Gör det här innan du börjar deploya, så slipper du rätta till det när något redan är i produktion.

Sätt lösenord och aktivera tvåfaktor direkt. Lägg sedan in faktureringsuppgifter: organisationsnummer, momsregistreringsnummer och en fakturaadress som går till ekonomi och inte till en personlig brevlåda. Lägg till minst en kollega med administratörsrättighet — ett konto som bara en person når är en driftrisk, inte en säkerhetsåtgärd.

Separera miljöer från början. Skapa projekt för produktion respektive test i stället för att lägga allt i ett, och namnge resurserna efter vad de gör. Det kostar inget att göra rätt nu och är omständligt att reda ut senare.

Välj region medvetet. Vi kör i Helsingfors, Falkenstein och Nürnberg. Latensen mellan app, databas och lagring är låg inom en region och märkbar mellan två, så lägg ihop det som pratar med varandra. Att byta region senare är inte en inställning — det är en ny resurs plus en datamigrering.

• Tvåfaktor på alla konton med administratörsrättighet
• Två kontaktvägar: en för fakturor, en för driftlarm
• Egna projekt för produktion och test
• Samma region för app, databas och lagring

Koppla en git-källa först. SIAX Git (Gitea), GitHub och GitLab fungerar; kopplingen görs antingen med OAuth eller med en deploy-nyckel om du hellre håller åtkomsten smal. Välj sedan repo och gren. Grenen du pekar ut blir produktionsgrenen — varje push dit bygger och deployar.

Finns en Dockerfile i repot används den. Saknas den försöker byggsteget känna igen projektet automatiskt. Automatisk igenkänning fungerar för vanliga Node-, Python- och Go-projekt, men en egen Dockerfile ger dig kontroll över byggsteget och är det vi rekommenderar för allt som ska leva längre än en demo.

Lägg in miljövariabler innan första deployen. Hemligheter går att skriva men inte att läsa tillbaka i klartext efteråt, så spara dem även hos dig. Appen måste lyssna på 0.0.0.0 och på porten i miljövariabeln PORT — hårdkodad 3000 på localhost är den vanligaste orsaken till att en bygg som lyckas ändå inte svarar. Sätt en hälsokontrollväg så att en trasig version inte tar över trafiken.

Egen domän pekas in med de värden konsolen visar. TLS-certifikatet utfärdas automatiskt när DNS-posten pekar rätt, vilket kan ta några minuter. Sätt inte en proxy eller CDN framför innan certifikatet är utfärdat — då misslyckas valideringen. Pull requests får egna preview-miljöer som städas när de mergas, och rollback till en tidigare version är ett klick.

• Byggverktyg i devDependencies måste installeras i byggsteget (npm ci --include=dev, eller ett flerstegs-Dockerfile)
• Lockfil måste vara committad, annars blir bygget inte reproducerbart
• Filsystemet är flyktigt: uppladdningar och genererade filer ska till objektlagringen
• Bakgrundsjobb och köer körs som egen tjänst, inte i samma process som webbservern
• Bygget kan behöva mer minne än driften — storleken går att ändra efteråt

Lägg upp din publika SSH-nyckel i konsolen innan du skapar maskinen, helst en ed25519-nyckel. Lösenordsinloggning är avstängd från start, så nyckeln är enda vägen in. Skapar du maskinen utan nyckel får du gå via konsolåtkomsten för att lägga in den efteråt.

Första inloggningen är ssh root@IP-adressen som står i konsolen. Gör sedan grundarbetet direkt: uppdatera paketen, skapa en användare med sudo, stäng av root-inloggning över SSH, slå på automatiska säkerhetsuppdateringar och sätt brandväggen. Öppna bara de portar du faktiskt använder. Låser du ute dig själv med brandväggsregeln finns konsolåtkomsten kvar — den går inte via SSH.

VPS är en maskin med root, inte en managerad plattform. Ögonblicksbilder ingår, men schemalagd backup är ett tillval du väljer vid beställning (daglig med sju dagars historik, eller varje timme med trettio dagar). Väljer du ingen backup är det du som sköter den. Går du vidare med e-postsändning från maskinen behöver du också sätta omvänd DNS på IP-adressen.

Dedikerad server fungerar annorlunda: vi installerar och patchar operativsystemet, övervakar maskinen och kör backup med verifierad återläsning. Du får åtkomstuppgifter vid överlämningen, 1–3 arbetsdagar efter beställning.

• ssh-keygen -t ed25519, lägg upp den publika delen i konsolen före provisionering
• apt update && apt full-upgrade, sedan en icke-root-användare med sudo
• PermitRootLogin no och PasswordAuthentication no i sshd_config
• Brandvägg med enbart de portar tjänsten behöver
• Konsolåtkomst i webbläsaren när SSH inte går fram

Konsolen ger dig värd, port, databasnamn, användare och lösenord, samt en färdig anslutningssträng på formen postgres://användare:lösenord@värd:5432/databas?sslmode=require. TLS är obligatoriskt; en klient som klagar på certifikatet är oftast en klient med gammalt CA-paket. Databasen når dina andra SIAX-resurser utan att exponeras publikt — öppna den mot internet bara om du verkligen behöver det, och begränsa i så fall till kända adresser.

Du får två anslutningssträngar: en poolad och en direkt. Använd den poolade för appar som öppnar många korta anslutningar, och den direkta för migreringar, schemaändringar, pg_dump och pg_restore. Sessionsberoende saker som prepared statements och LISTEN/NOTIFY hör hemma på den direkta.

För att flytta in data: ta en dump med pg_dump -Fc från källan och läs in med pg_restore --no-owner --no-privileges -j4 mot den nya databasen. Använd klientverktyg som matchar Postgres 17, annars klagar dumpen på formatversion. Kontrollera vilka tillägg du använder innan du börjar — vanliga tillägg finns, men bygger din applikation på ett tillägg vi inte kör måste det redas ut före migreringen, inte under.

Var realistisk om stilleståndet. Dump och återläsning innebär att skrivningar måste stoppas under tiden: några gigabyte tar minuter, hundratals gigabyte tar timmar, och index byggs om efter återläsningen. Vill du ner mot noll stillestånd krävs logisk replikering med en planerad växling, vilket är ett eget arbete och inte något som klaras av på en eftermiddag. Sådant som inte följer med i en dump — leverantörsspecifik auth, radnivåpolicyer knutna till en plattforms egen användartabell, serverlösa autoskalningsinställningar, parametergrupper — måste byggas om.

• pg_dump -Fc -d källa -f dump.pgc
• pg_restore --no-owner --no-privileges -j4 -d målsträngen dump.pgc
• Kör ANALYZE efter återläsning innan du släpper på trafik
• Verifiera radantal per tabell mot källan innan du växlar DNS eller anslutningssträng
• Point-in-time recovery finns, men testa återläsning på en kopia innan du behöver den skarpt

Skapa en bucket i konsolen och generera sedan ett åtkomstnyckelpar. Hemligheten visas en gång — lägg den i din hemlighetshantering direkt. Endpoint-URL:en står bredvid nycklarna och är den enda inställning utöver nycklarna som du behöver ändra i befintlig kod: API:et är S3-kompatibelt, så AWS SDK, boto3, aws-cli, rclone och s3cmd fungerar som de är.

Två detaljer brukar stoppa upp första försöket. Sätt path-style-adressering (forcePathStyle i SDK:erna) i stället för virtual-host-style. Och fyll i region-fältet även om det inte betyder något hos oss — flera SDK:er vägrar starta utan värde. Verifiera med aws s3 ls --endpoint-url=... innan du felsöker i applikationen. Flyttar du in data från S3 eller Blob Storage är rclone copy med kontrollsummor det enkla vägvalet; räkna med att publika buckets behöver ersättas av signerade URL:er, eftersom ACL-modellerna inte är identiska. Utgående trafik upp till tre gånger lagrad volym ingår.

Backupprodukten är vanlig restic mot en rest-server-endpoint som är din. Initiera repot med restic -r rest:https://... init, ange ett repolösenord och lagra det någon annanstans än på maskinen som säkerhetskopieras. Krypteringen sker på din sida innan data lämnar maskinen, vilket också betyder att ett förlorat repolösenord gör backupen oläsbar — vi kan inte återskapa den, och det är hela poängen med konstruktionen.

Schemalägg jobbet med systemd timer eller cron, kör restic forget --prune enligt din gallringspolicy och restic check regelbundet. Återläsningsövningen körs enligt schema från vår sida och loggas med datum, så att du har underlag på att återläsningen fungerade och inte bara att jobbet startade.

• restic -r rest:https://endpoint/repo init
• restic backup /sökväg --verbose, med lösenordet i en fil som bara root kan läsa
• restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
• restic restore latest --target /tmp/test — gör den övningen själv också, första veckan

E-post fungerar inte förrän fyra saker stämmer i DNS. Konsolen visar de exakta värdena för din domän; formen ser ut så här.

MX pekar på den värd konsolen anger, med prioritet 10, och gamla MX-poster ska bort — inte ligga kvar som reserv. SPF är en TXT-post på domänens rot, och det får bara finnas en: har du redan andra avsändare (fakturasystem, nyhetsbrev) slår du ihop dem i samma post. DKIM läggs som den post och selektor konsolen visar. DMARC är en TXT-post på _dmarc med rapportadress.

Ordningen spelar roll vid en flytt. Skapa brevlådorna och låt migreringen från Google Workspace eller Microsoft 365 synka klart först — den ingår i priset och gör vi åt dig. Sänk TTL på MX-posten till 300 sekunder ett dygn innan växlingen. Byt MX sist. Räkna med en period där brev landar på båda ställena medan resolvers hinner ikapp; det är normalt och inte ett fel.

En ärlig varning om leveransbarhet: en domän som börjar skicka från en ny infrastruktur har ingen upparbetad historik hos mottagande operatörer. Kör DMARC med p=none i ett par veckor, läs rapporterna, och skärp sedan till p=quarantine och därefter p=reject. Skicka inte ett stort utskick första dagen — då bygger du en dålig start som tar veckor att arbeta bort. Ligger DNS hos en annan leverantör går det utmärkt, men då är propagering och ändringar deras domän, inte vår.

För domänflytt hit behöver domänen vara upplåst hos nuvarande registrar och du behöver auth-koden. En .se-överföring tar normalt runt fem dagar. DNS kan skötas i gränssnittet eller som kod med octoDNS om du hellre versionshanterar zonen.

• MX: värden från konsolen, prioritet 10, gamla poster borttagna
• SPF: en enda TXT-post på roten, alla legitima avsändare inkluderade, avslut med -all
• DKIM: posten och selektorn som konsolen visar, per domän
• DMARC: TXT på _dmarc, börja med p=none och en rua-adress du faktiskt läser
• TTL 300 innan växling, tillbaka till normalvärde efteråt

Git-importen tar med historik, issues och pull requests. Du anger repo-URL och en åtkomsttoken till källan, och kan välja spegling om du vill låta gamla stället ligga kvar som läskopia under övergången. Byggminuterna mäts inte — CI körs på din plan. Efter växlingen uppdaterar du fjärranslutningen med git remote set-url och pekar om webhooks och driftflöden.

Var ärlig mot dig själv om CI-flyttet. Enkla arbetsflöden körs som de är av act_runner, men steg som anropar källplattformens eget API, marknadsplatsåtgärder som förutsätter den plattformen, och OIDC-federation mot tredje part måste skrivas om. Räkna med en halv till en dag för en normal pipeline, mer om den är byggd med många färdiga åtgärder.

Övervakningen kommer du igång med på några minuter: lägg upp kontroller mot dina URL:er, TCP-portar, certifikat och cron-jobb, koppla larm till e-post, Slack, Telegram eller webhook, och slå på en publik statussida om du vill visa kunder läget. Tio kontroller är gratis utan tidsgräns och utan kortuppgifter.

AI-gatewayen exponerar ett OpenAI-kompatibelt API. Skapa en virtuell nyckel per projekt, sätt budgettak, och peka om bas-URL:en i din klient — koden behöver i övrigt inte ändras. Leverantörsnycklarna ligger i gatewayen, inte i applikationen, vilket också är poängen: du kan byta modell utan att röra koden och ser varje anrop i spårningsvyn. Vill du hålla trafiken inom EU styr du den till modeller som körs på vår egen flotta, men var medveten om att de öppna modellerna inte är utbytbara mot de största proprietära i alla uppgifter — testa mot din egen utvärdering innan du byter i produktion.

• Importera repo med token, kör spegling under övergångsperioden
• git remote set-url origin, uppdatera webhooks och deploy-nycklar
• Paketregister för npm och Docker ingår — peka om .npmrc och docker login
• Övervakning: 10 kontroller gratis, larm till Slack eller webhook
• AI-gateway: en virtuell nyckel och ett budgettak per projekt

Nästan alla ärenden vi får dygn ett handlar om samma handfull saker, och de flesta går att lösa direkt. Innan du skriver till oss: kontrollera att DNS faktiskt pekar dit du tror (dig +short), att appen lyssnar på 0.0.0.0 och rätt port, och att SDK:n har både region och path-style satta mot objektlagringen.

Behöver du oss finns supportformuläret i konsolen på varje resurs — ett ärende därifrån får med sig vilken resurs det gäller, vilket sparar en runda frågor. Du kan också svara direkt på orderbekräftelsen. Svarstider och åtaganden står i SLA-villkoren; vi anger dem inte här för att slippa två versioner av samma löfte. Plattformsstörningar publiceras på statussidan, och för migreringar som är större än en eftermiddag går det att beställa hjälp som uppdrag i stället för att kämpa själv.

En sak att veta redan från start: SIAX har inte ISO 27001, SOC 2 eller PCI-DSS. Det vi har är GDPR-efterlevnad med personuppgiftsbiträdesavtal, all data i EU, och en stack av öppen källkod som du kan granska och lämna. Kräver din upphandling ett certifikat är vi fel leverantör i dag, och det är bättre att du vet det innan migreringen än efter.

• Inget inloggningsmejl: kolla skräpposten, begär ny länk — den gamla är engångs och kortlivad
• Certifikat utfärdas inte: DNS pekar inte rätt än, eller så står en proxy framför under valideringen
• 502 efter lyckat bygge: appen lyssnar på localhost eller hårdkodad port i stället för PORT
• Postgres nekar anslutning: sslmode saknas, eller så försöker du nå den utifrån utan att ha öppnat för det
• S3-anrop misslyckas: region-fältet tomt eller virtual-host-style i stället för path-style
• E-post hamnar i skräp: SPF, DKIM och DMARC på plats men domänen saknar ännu sändningshistorik