Näin pääset alkuun SIAX Platformin kanssa

Tilaaminen alkaa tuotesivulta. Valitset kokoonpanon konfiguraattorissa, näet hinnan päivittyvän ja teet tilauksen. Hinta lasketaan aina uudelleen palvelimella ennen tilauksen luomista, joten checkoutissa näkyvä summa on se, joka laskutetaan. Tilaamiseen ei tarvita tiliä — riittää sähköpostiosoite, ja tili luodaan maksun jälkeen.

Maksun jälkeen saat kaksi sähköpostia: tilausvahvistuksen, josta näkyy mitä ostit ja millä hinnalla, sekä kirjautumislinkin, joka luo tilin. Linkki on kertakäyttöinen ja lyhytikäinen. Jos se on vanhentunut tai ei koskaan saapunut, pyydä uusi kirjautumissivulta ja tarkista ensin roskaposti — vahvistusviestit päätyvät sinne useammin kuin luulisi.

Kun tili on luotu, tilaamasi resurssi provisioidaan. Useimmat palvelut ovat käytössä ennen kuin ehdit täyttää laskutustiedot. Poikkeus on dedikoitu palvelin: se tarkistetaan manuaalisesti, koska fyysistä laitteistoa pitää kohdentaa, ja saat ilmoituksen suunnitellusta luovutuspäivästä valmiin koneen sijaan.

Kaikki sivuston hinnat ovat ilman arvonlisäveroa ja ilmoitettu kuukausihintana, ellei toisin mainita. Verkkotunnukset laskutetaan vuosittain.

• App Hosting: käytössä alle minuutissa
• VPS: valmis 2–3 minuutissa
• Managed Postgres: valmis alle minuutissa
• Objektitallennus, varmuuskopiointi ja valvonta: heti
• Verkkotunnus, sähköposti, git ja CI, AI-yhdyskäytävä: minuutteja
• Dedikoitu palvelin: 1–3 arkipäivää, manuaalinen tarkistus

Tee nämä ennen kuin aloitat julkaisemisen, niin vältät korjailun siinä vaiheessa kun jokin on jo tuotannossa.

Aseta salasana ja ota kaksivaiheinen tunnistautuminen käyttöön heti. Lisää sitten laskutustiedot: yritys- ja alv-tunnus sekä laskutusosoite, joka menee taloushallinnolle eikä henkilökohtaiseen postilaatikkoon. Lisää vähintään yksi kollega, jolla on ylläpitäjän oikeudet — tili, johon pääsee käsiksi vain yksi henkilö, on käyttövarmuusriski, ei turvatoimi.

Erota ympäristöt heti alusta. Luo erilliset projektit tuotannolle ja testaukselle sen sijaan, että laittaisit kaiken samaan, ja nimeä resurssit sen mukaan, mitä ne tekevät. Oikein tekeminen ei maksa nyt mitään, mutta jälkikäteen selvittely on työlästä.

Valitse alue harkiten. Ajamme palveluita Helsingissä, Falkensteinissa ja Nürnbergissä. Sovelluksen, tietokannan ja tallennustilan välinen viive on pieni saman alueen sisällä ja huomattava kahden alueen välillä, joten pidä keskenään kommunikoivat resurssit samassa alueessa. Alueen vaihtaminen jälkikäteen ei ole asetus — se on uusi resurssi ja datamigraatio.

• Kaksivaiheinen tunnistautuminen kaikille tileille, joilla on ylläpitäjän oikeudet
• Kaksi yhteydenottotapaa: yksi laskuille, yksi käyttöhälytyksille
• Omat projektit tuotannolle ja testaukselle
• Sama alue sovellukselle, tietokannalle ja tallennustilalle

Yhdistä git-lähde ensin. SIAX Git (Gitea), GitHub ja GitLab toimivat; yhdistäminen tehdään joko OAuthilla tai deploy-avaimella, jos haluat pitää käyttöoikeudet suppeampina. Valitse sitten repo ja haara. Osoittamastasi haarasta tulee tuotantohaara — jokainen sinne tehty push käynnistää buildin ja julkaisun.

Jos repossa on Dockerfile, sitä käytetään. Jos sitä ei ole, build-vaihe yrittää tunnistaa projektin automaattisesti. Automaattinen tunnistus toimii tavallisille Node-, Python- ja Go-projekteille, mutta oma Dockerfile antaa sinulle hallinnan build-vaiheesta, ja suosittelemme sitä kaikkeen, minkä on tarkoitus elää demoa pidempään.

Lisää ympäristömuuttujat ennen ensimmäistä julkaisua. Salaisuudet voi kirjoittaa, mutta niitä ei voi enää lukea selväkielisenä jälkikäteen, joten tallenna ne myös itsellesi. Sovelluksen on kuunneltava osoitetta 0.0.0.0 ja PORT-ympäristömuuttujassa annettua porttia — kovakoodattu 3000 osoitteessa localhost on yleisin syy siihen, että onnistuneesti buildattu sovellus ei silti vastaa. Aseta terveystarkistuspolku, jotta rikkinäinen versio ei ota liikennettä vastaan.

Oma verkkotunnus osoitetaan konsolissa näkyvillä arvoilla. TLS-varmenne myönnetään automaattisesti, kun DNS-tietue osoittaa oikein, mikä voi kestää muutaman minuutin. Älä laita proxya tai CDN:ää eteen ennen kuin varmenne on myönnetty — silloin validointi epäonnistuu. Pull requestit saavat omat esikatseluympäristönsä, jotka siivotaan pois, kun ne yhdistetään, ja palautus aiempaan versioon on yhden klikkauksen takana.

• devDependencies-riippuvuuksissa olevat build-työkalut on asennettava build-vaiheessa (npm ci --include=dev tai monivaiheinen Dockerfile)
• Lock-tiedosto on oltava committoitu, muuten build ei ole toistettavissa
• Tiedostojärjestelmä on väliaikainen: lataukset ja generoidut tiedostot kuuluvat objektitallennukseen
• Taustatyöt ja jonot ajetaan omana palveluna, ei samassa prosessissa kuin verkkopalvelin
• Build saattaa tarvita enemmän muistia kuin ajoaikainen käyttö — kokoa voi muuttaa jälkikäteen

Lisää julkinen SSH-avaimesi konsoliin ennen koneen luomista, mieluiten ed25519-avain. Salasanakirjautuminen on pois päältä alusta asti, joten avain on ainoa tie sisään. Jos luot koneen ilman avainta, joudut lisäämään sen jälkikäteen konsolin kautta.

Ensimmäinen kirjautuminen tapahtuu komennolla ssh root@IP-osoite, joka näkyy konsolissa. Tee sitten perustyöt heti: päivitä paketit, luo sudo-oikeuksin varustettu käyttäjä, sulje root-kirjautuminen SSH:n kautta, ota käyttöön automaattiset tietoturvapäivitykset ja aseta palomuuri. Avaa vain ne portit, joita oikeasti käytät. Jos lukitset itsesi ulos palomuurisäännöllä, konsolin kautta pääsee silti sisään — se ei kulje SSH:n kautta.

VPS on kone, jossa on root-oikeudet, ei hallittu alusta. Tilannevedokset sisältyvät, mutta ajastettu varmuuskopiointi on tilauksen yhteydessä valittava lisäosa (päivittäinen seitsemän päivän historialla tai tunnin välein kolmenkymmenen päivän historialla). Jos et valitse varmuuskopiointia, sen hoitaminen jää sinulle. Jos aiot lähettää sähköpostia koneelta, sinun täytyy myös asettaa käänteinen DNS IP-osoitteelle.

Dedikoitu palvelin toimii eri tavalla: me asennamme ja päivitämme käyttöjärjestelmän, valvomme konetta ja ajamme varmuuskopioinnin, jonka palautus on varmennettu. Saat käyttötunnukset luovutuksen yhteydessä, 1–3 arkipäivää tilauksesta.

• ssh-keygen -t ed25519, lisää julkinen osa konsoliin ennen provisiointia
• apt update && apt full-upgrade, sitten sudo-oikeuksin varustettu ei-root-käyttäjä
• PermitRootLogin no ja PasswordAuthentication no tiedostossa sshd_config
• Palomuuri, jossa on auki vain palvelun tarvitsemat portit
• Konsolipääsy selaimessa, kun SSH ei toimi

Konsoli antaa sinulle host-nimen, portin, tietokannan nimen, käyttäjätunnuksen ja salasanan sekä valmiin yhteysmerkkijonon muodossa postgres://käyttäjä:salasana@host:5432/tietokanta?sslmode=require. TLS on pakollinen; asiakasohjelma, joka valittaa varmenteesta, käyttää yleensä vanhentunutta CA-pakettia. Tietokanta on muiden SIAX-resurssiesi käytettävissä ilman että se on julkisesti näkyvillä — avaa se internetiin vain jos todella tarvitset sitä, ja rajaa se silloin tunnettuihin osoitteisiin.

Saat kaksi yhteysmerkkijonoa: pooloitun ja suoran. Käytä pooloitua sovelluksille, jotka avaavat paljon lyhyitä yhteyksiä, ja suoraa migraatioihin, skeeman muutoksiin, pg_dumpiin ja pg_restoreen. Istuntokohtaiset asiat, kuten prepared statementit ja LISTEN/NOTIFY, kuuluvat suoralle yhteydelle.

Datan siirtämiseksi: ota dumppi komennolla pg_dump -Fc lähteestä ja lue se sisään komennolla pg_restore --no-owner --no-privileges -j4 uutta tietokantaa vasten. Käytä Postgres 17:ää vastaavia asiakastyökaluja, muuten dumppi valittaa formaattiversiosta. Tarkista käyttämäsi laajennukset ennen aloittamista — yleiset laajennukset löytyvät, mutta jos sovelluksesi nojaa laajennukseen, jota emme aja, asia täytyy selvittää ennen migraatiota, ei sen aikana.

Ole realistinen käyttökatkon suhteen. Dumppi ja palautus edellyttävät, että kirjoitukset pysäytetään sen ajaksi: muutama gigatavu vie minuutteja, sadat gigatavut vievät tunteja, ja indeksit rakennetaan uudelleen palautuksen jälkeen. Jos haluat lähelle nollakatkosta, tarvitset loogisen replikoinnin ja suunnitellun vaihdon, mikä on oma erillinen työnsä eikä hoidu iltapäivässä. Asiat, jotka eivät seuraa dumpin mukana — toimittajakohtainen autentikointi, alustan omaan käyttäjätauluun sidotut rivitason käytännöt, serverless-alustan automaattiskaalausasetukset, parametriryhmät — täytyy rakentaa uudelleen.

• pg_dump -Fc -d lähde -f dump.pgc
• pg_restore --no-owner --no-privileges -j4 -d kohdemerkkijono dump.pgc
• Aja ANALYZE palautuksen jälkeen ennen kuin päästät liikenteen läpi
• Vahvista rivimäärät taulukoittain lähteeseen verrattuna ennen kuin vaihdat DNS:n tai yhteysmerkkijonon
• Point-in-time recovery on käytettävissä, mutta testaa palautus kopiolla ennen kuin tarvitset sitä oikeasti

Luo bucket konsolissa ja generoi sitten avainpari. Salaisuus näytetään vain kerran — vie se heti salaisuuksienhallintaan. Endpoint-URL näkyy avainten vieressä, ja se on ainoa asetus avainten lisäksi, jonka joudut muuttamaan olemassa olevaan koodiin: rajapinta on S3-yhteensopiva, joten AWS SDK, boto3, aws-cli, rclone ja s3cmd toimivat sellaisenaan.

Kaksi yksityiskohtaa pysäyttää yleensä ensimmäisen yrityksen. Käytä path-style-osoitusta (forcePathStyle SDK:issa) virtual-host-stylen sijaan. Täytä myös region-kenttä, vaikka sillä ei meillä ole merkitystä — useat SDK:t kieltäytyvät käynnistymästä ilman arvoa. Varmista tilanne komennolla aws s3 ls --endpoint-url=... ennen kuin alat vianetsiä sovelluksesta. Jos siirrät dataa S3:sta tai Blob Storagesta, rclone copy tarkistussummien kanssa on helpoin reitti; varaudu siihen, että julkiset bucketit pitää korvata allekirjoitetuilla URL-osoitteilla, koska ACL-mallit eivät ole identtiset. Lähtevä liikenne aina kolminkertaiseen tallennettuun määrään asti sisältyy hintaan.

Varmuuskopiointituote on tavallinen restic omaa rest-server-endpointtiasi vasten. Alusta repo komennolla restic -r rest:https://... init, aseta repon salasana ja säilytä sitä muualla kuin koneella, jota varmuuskopioidaan. Salaus tapahtuu sinun puolellasi ennen kuin data lähtee koneelta, mikä tarkoittaa myös sitä, että kadonnut repon salasana tekee varmuuskopiosta lukukelvottoman — emme voi palauttaa sitä, ja se on koko rakenteen tarkoitus.

Ajasta työ systemd timerilla tai cronilla, aja restic forget --prune karsimiskäytäntösi mukaisesti ja restic check säännöllisesti. Palautusharjoitus ajetaan aikataulun mukaan meidän puoleltamme ja kirjataan lokiin päivämäärineen, jotta sinulla on todiste siitä, että palautus toimi eikä vain että työ käynnistyi.

• restic -r rest:https://endpoint/repo init
• restic backup /polku --verbose, salasana tiedostossa, jota vain root voi lukea
• restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
• restic restore latest --target /tmp/test — tee tämä harjoitus myös itse, ensimmäisellä viikolla

Sähköposti ei toimi ennen kuin neljä asiaa on kunnossa DNS:ssä. Konsoli näyttää tarkat arvot verkkotunnuksellesi; muoto näyttää tältä.

MX osoittaa konsolin ilmoittamaan host-nimeen prioriteetilla 10, ja vanhat MX-tietueet pitää poistaa — ei jättää varalle. SPF on TXT-tietue verkkotunnuksen juuressa, ja niitä saa olla vain yksi: jos sinulla on jo muita lähettäjiä (laskutusjärjestelmä, uutiskirje), yhdistä ne samaan tietueeseen. DKIM lisätään konsolin näyttämällä tietueella ja selektorilla. DMARC on TXT-tietue kohdassa _dmarc, jossa on raportointiosoite.

Järjestyksellä on väliä siirron yhteydessä. Luo postilaatikot ja anna Google Workspacesta tai Microsoft 365:stä tehtävän migraation synkronoitua loppuun ensin — se sisältyy hintaan ja hoidamme sen puolestasi. Laske MX-tietueen TTL 300 sekuntiin vuorokausi ennen vaihtoa. Vaihda MX viimeisenä. Varaudu jaksoon, jolloin viestit saapuvat molempiin paikkoihin resolverien ehtiessä kirimään perässä; se on normaalia eikä virhe.

Rehellinen varoitus toimitettavuudesta: verkkotunnus, joka alkaa lähettää uudesta infrastruktuurista, ei ole vielä kerännyt historiaa vastaanottavien operaattoreiden silmissä. Aja DMARC-asetuksella p=none pari viikkoa, lue raportit ja kiristä sitten tilaan p=quarantine ja sen jälkeen p=reject. Älä lähetä isoa massalähetystä ensimmäisenä päivänä — silloin rakennat huonon lähtökohdan, jonka korjaaminen vie viikkoja. Jos DNS on toisella palveluntarjoajalla, se sopii hyvin, mutta silloin propagointi ja muutokset ovat heidän vastuullaan, ei meidän.

Verkkotunnuksen siirtämiseksi meille verkkotunnuksen täytyy olla lukitsematon nykyisellä rekisterinpitäjällä, ja tarvitset auth-koodin. .se-siirto kestää yleensä noin viisi päivää. DNS:ää voi hallita käyttöliittymässä tai koodina octoDNS:llä, jos haluat mieluummin versionhallita vyöhykkeen.

• MX: arvot konsolista, prioriteetti 10, vanhat tietueet poistettu
• SPF: yksi ainoa TXT-tietue juuressa, kaikki lailliset lähettäjät mukana, päättyy merkintään -all
• DKIM: konsolin näyttämä tietue ja selektori, verkkotunnuskohtaisesti
• DMARC: TXT kohdassa _dmarc, aloita arvolla p=none ja rua-osoitteella, jota oikeasti luet
• TTL 300 ennen vaihtoa, takaisin normaaliarvoon jälkeenpäin

Git-tuonti tuo mukanaan historian, issuet ja pull requestit. Annat repon URL-osoitteen ja lähteen käyttöoikeustunnuksen ja voit valita peilauksen, jos haluat pitää vanhan paikan lukukopiona siirtymän ajan. Build-minuutteja ei mitata — CI ajetaan omalla tasollasi. Vaihdon jälkeen päivität etäyhteyden komennolla git remote set-url ja ohjaat webhookit ja työnkulut uudelleen.

Ole rehellinen itsellesi CI:n siirrosta. Yksinkertaiset työnkulut ajaa act_runner sellaisenaan, mutta vaiheet, jotka kutsuvat lähdealustan omaa API:a, alustaan sidotut markkinapaikkatoiminnot ja OIDC-federointi kolmansiin osapuoliin täytyy kirjoittaa uudelleen. Varaa puolesta päivästä päivään tavalliselle pipelinelle, enemmän jos se on rakennettu monista valmiista toiminnoista.

Valvonnan saat käyntiin muutamassa minuutissa: lisää tarkistuksia URL-osoitteillesi, TCP-porteille, varmenteille ja cron-töille, kytke hälytykset sähköpostiin, Slackiin, Telegramiin tai webhookiin, ja ota käyttöön julkinen tilasivu, jos haluat näyttää tilanteen asiakkaille. Kymmenen tarkistusta on ilmaisia ilman aikarajaa ja ilman korttitietoja.

AI-yhdyskäytävä tarjoaa OpenAI-yhteensopivan rajapinnan. Luo virtuaalinen avain per projekti, aseta budjettikatto ja ohjaa asiakasohjelmasi base-URL uudelleen — muuta koodia ei tarvitse muuttaa. Toimittajien avaimet sijaitsevat yhdyskäytävässä, ei sovelluksessa, mikä on koko idea: voit vaihtaa mallia koskematta koodiin ja näet jokaisen kutsun jäljitysnäkymässä. Jos haluat pitää liikenteen EU:n sisällä, ohjaa se malleihin, jotka ajetaan omalla flotallamme, mutta ota huomioon, etteivät avoimet mallit korvaa suurimpia omisteisia malleja kaikissa tehtävissä — testaa omaa arviointiasi vasten ennen kuin vaihdat tuotannossa.

• Tuo repo tokenilla, aja peilaus siirtymäkauden ajan
• git remote set-url origin, päivitä webhookit ja deploy-avaimet
• Pakettirekisteri npm:lle ja Dockerille sisältyy — ohjaa .npmrc ja docker login uudelleen
• Valvonta: 10 tarkistusta ilmaiseksi, hälytykset Slackiin tai webhookiin
• AI-yhdyskäytävä: virtuaalinen avain ja budjettikatto per projekti

Lähes kaikki ensimmäisen vuorokauden aikana saamamme yhteydenotot koskevat samaa kourallista asioita, ja useimmat pystyy ratkaisemaan heti itse. Ennen kuin otat meihin yhteyttä: tarkista, että DNS todella osoittaa sinne minne luulet (dig +short), että sovellus kuuntelee osoitetta 0.0.0.0 ja oikeaa porttia, ja että SDK:ssa on sekä region että path-style asetettu objektitallennusta varten.

Jos tarvitset meitä, tukilomake löytyy konsolista jokaisen resurssin kohdalla — sitä kautta lähetetty tapaus sisältää tiedon siitä, mitä resurssia se koskee, mikä säästää yhden kysymyskierroksen. Voit myös vastata suoraan tilausvahvistukseen. Vasteajat ja sitoumukset on kerrottu SLA-ehdoissa; emme toista niitä tässä, jottei samasta lupauksesta synny kahta versiota. Alustan häiriöt julkaistaan tilasivulla, ja iltapäivää suuremmille migraatioille voi tilata apua toimeksiantona sen sijaan, että tekisi sen yksin.

Yksi asia kannattaa tietää heti alusta: SIAXilla ei ole ISO 27001-, SOC 2- eikä PCI-DSS-sertifiointia. Se mitä meillä on, on GDPR-vaatimustenmukaisuus henkilötietojen käsittelysopimuksineen, kaikki data EU:ssa ja avoimen lähdekoodin pinorakenne, jonka voit tarkastaa ja josta voit lähteä. Jos kilpailutuksesi edellyttää sertifikaattia, olemme tänään väärä toimittaja, ja on parempi että tiedät sen ennen migraatiota kuin sen jälkeen.

• Ei kirjautumissähköpostia: tarkista roskaposti, pyydä uusi linkki — vanha on kertakäyttöinen ja lyhytikäinen
• Varmennetta ei myönnetä: DNS ei vielä osoita oikein, tai proxy on validoinnin ajan edessä
• 502 onnistuneen buildin jälkeen: sovellus kuuntelee osoitetta localhost tai kovakoodattua porttia PORT-muuttujan sijaan
• Postgres hylkää yhteyden: sslmode puuttuu, tai yrität tavoittaa sen ulkopuolelta ilman että olet avannut sitä varten
• S3-kutsu epäonnistuu: region-kenttä tyhjä tai virtual-host-style path-stylen sijaan
• Sähköposti päätyy roskapostiin: SPF, DKIM ja DMARC kunnossa, mutta verkkotunnukselta puuttuu vielä lähetyshistoria