Getting started with SIAX Platform

The order starts on the product page. You choose a configuration in the configurator, watch the price update, and place the order. The price is always recalculated on the server before the order is created, so the amount at checkout is what gets billed. You don't need an account to order — an email address is enough; the account is created after payment.

After payment, you get two emails: an order confirmation with what you bought and at what price, and a login link that creates the account. The link is a single-use link with a short lifetime. If it's expired or never arrived, request a new one from the login page and check your spam folder first — confirmation emails end up there more often than you'd think.

Once the account is created, what you ordered is provisioned. Most services are up before you've finished filling in your billing details. The exception is dedicated server: it's reviewed manually since physical hardware has to be allocated, and you get a notice with a planned handover date instead of a ready machine.

All prices on the site are exclusive of VAT and stated as a monthly price unless otherwise noted. Domains are billed annually.

• App Hosting: live in under a minute
• VPS: ready in 2–3 minutes
• Managed Postgres: ready in under a minute
• Object storage, backup and monitoring: instant
• Domain, email, git and CI, AI gateway: minutes
• Dedicated server: 1–3 business days, manual review

Do this before you start deploying, so you don't have to fix it once something's already in production.

Set a password and turn on two-factor right away. Then add billing details: organization number, VAT registration number, and an invoice address that goes to finance, not a personal mailbox. Add at least one colleague with administrator rights — an account only one person can reach is an operational risk, not a security measure.

Separate environments from the start. Create separate projects for production and test instead of putting everything in one, and name resources for what they do. It costs nothing to do it right now and is a hassle to untangle later.

Choose a region deliberately. We run in Helsinki, Falkenstein and Nuremberg. Latency between app, database and storage is low within a region and noticeable between two, so keep things that talk to each other together. Changing region later isn't a setting — it's a new resource plus a data migration.

• Two-factor on every account with administrator rights
• Two contact channels: one for invoices, one for operational alerts
• Separate projects for production and test
• Same region for app, database and storage

Connect a git source first. SIAX Git (Gitea), GitHub and GitLab all work; the connection is made either via OAuth or a deploy key if you'd rather keep access narrow. Then choose the repo and branch. The branch you point to becomes the production branch — every push there builds and deploys.

If there's a Dockerfile in the repo, it's used. If not, the build step tries to detect the project automatically. Auto-detection works for common Node, Python and Go projects, but your own Dockerfile gives you control over the build step and is what we recommend for anything meant to live longer than a demo.

Add environment variables before the first deploy. Secrets can be written but not read back in plaintext afterward, so keep a copy of your own as well. The app must listen on 0.0.0.0 and on the port in the PORT environment variable — a hardcoded 3000 on localhost is the most common reason a successful build still doesn't respond. Set a health check path so a broken version doesn't take over traffic.

A custom domain is pointed using the values the console shows. The TLS certificate is issued automatically once the DNS record points correctly, which can take a few minutes. Don't put a proxy or CDN in front before the certificate is issued — that makes validation fail. Pull requests get their own preview environments that are cleaned up on merge, and rolling back to a previous version is one click.

• Build tools in devDependencies must be installed at build time (npm ci --include=dev, or a multi-stage Dockerfile)
• The lockfile must be committed, or the build won't be reproducible
• The filesystem is ephemeral: uploads and generated files should go to object storage
• Background jobs and queues run as their own service, not in the same process as the web server
• The build may need more memory than production runtime — the size can be changed afterward

Add your public SSH key in the console before creating the machine, preferably an ed25519 key. Password login is disabled from the start, so the key is the only way in. If you create the machine without a key, you'll need to use console access to add it afterward.

The first login is ssh root@ the IP address shown in the console. Then do the groundwork right away: update packages, create a user with sudo, disable root login over SSH, turn on automatic security updates, and set up the firewall. Only open the ports you actually use. If you lock yourself out with a firewall rule, console access is still there — it doesn't go through SSH.

A VPS is a machine with root access, not a managed platform. Snapshots are included, but scheduled backup is an add-on you choose at order time (daily with seven days of history, or hourly with thirty days). If you don't choose backup, it's on you to handle it. If you go on to send email from the machine, you'll also need to set reverse DNS on the IP address.

Dedicated server works differently: we install and patch the operating system, monitor the machine, and run backups with verified restores. You get access credentials at handover, 1–3 business days after ordering.

• ssh-keygen -t ed25519, add the public part in the console before provisioning
• apt update && apt full-upgrade, then a non-root user with sudo
• PermitRootLogin no and PasswordAuthentication no in sshd_config
• Firewall with only the ports the service needs
• Browser console access for when SSH isn't reachable

The console gives you host, port, database name, user and password, plus a ready-made connection string in the form postgres://user:password@host:5432/database?sslmode=require. TLS is mandatory; a client complaining about the certificate is usually a client with an outdated CA bundle. The database reaches your other SIAX resources without being publicly exposed — only open it to the internet if you truly need to, and if so, restrict it to known addresses.

You get two connection strings: a pooled one and a direct one. Use the pooled one for apps that open many short connections, and the direct one for migrations, schema changes, pg_dump and pg_restore. Session-dependent things like prepared statements and LISTEN/NOTIFY belong on the direct one.

To move in data: take a dump with pg_dump -Fc from the source and load it with pg_restore --no-owner --no-privileges -j4 against the new database. Use client tools that match Postgres 17, or the dump will complain about the format version. Check which extensions you're using before you start — common extensions are available, but if your application relies on an extension we don't run, that needs to be sorted out before the migration, not during it.

Be realistic about the downtime. Dump and restore means writes must stop during the process: a few gigabytes takes minutes, hundreds of gigabytes takes hours, and indexes are rebuilt after the restore. If you want close to zero downtime, you need logical replication with a planned cutover, which is its own piece of work and not something wrapped up in an afternoon. Things that don't carry over in a dump — provider-specific auth, row-level policies tied to a platform's own user table, serverless autoscaling settings, parameter groups — have to be rebuilt.

• pg_dump -Fc -d source -f dump.pgc
• pg_restore --no-owner --no-privileges -j4 -d target-string dump.pgc
• Run ANALYZE after restore before letting traffic through
• Verify row counts per table against the source before switching DNS or connection string
• Point-in-time recovery is available, but test a restore on a copy before you need it for real

Create a bucket in the console, then generate an access key pair. The secret is shown once — put it in your secrets manager right away. The endpoint URL sits next to the keys and is the only setting besides the keys you need to change in existing code: the API is S3-compatible, so AWS SDK, boto3, aws-cli, rclone and s3cmd work as they are.

Two details usually trip up the first attempt. Set path-style addressing (forcePathStyle in the SDKs) instead of virtual-host style. And fill in the region field even though it doesn't mean anything on our end — several SDKs refuse to start without a value. Verify with aws s3 ls --endpoint-url=... before troubleshooting in the application. If you're moving data in from S3 or Blob Storage, rclone copy with checksums is the easy route; expect public buckets to need replacing with signed URLs, since the ACL models aren't identical. Outbound traffic up to three times the stored volume is included.

The backup product is plain restic against a rest-server endpoint that's yours. Initialize the repo with restic -r rest:https://... init, set a repo password, and store it somewhere other than the machine being backed up. Encryption happens on your side before data leaves the machine, which also means a lost repo password makes the backup unreadable — we can't recover it, and that's the whole point of the design.

Schedule the job with a systemd timer or cron, run restic forget --prune per your retention policy, and restic check regularly. The restore drill runs on a schedule from our side and is logged with a date, so you have evidence that the restore actually worked, not just that the job started.

• restic -r rest:https://endpoint/repo init
• restic backup /path --verbose, with the password in a file only root can read
• restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
• restic restore latest --target /tmp/test — run that drill yourself too, in the first week

Email doesn't work until four things are correct in DNS. The console shows the exact values for your domain; the shape looks like this.

MX points to the host the console specifies, at priority 10, and old MX records should be removed — not left as a fallback. SPF is a TXT record at the domain root, and there can only be one: if you already have other senders (invoicing system, newsletter), merge them into the same record. DKIM is added as the record and selector the console shows. DMARC is a TXT record at _dmarc with a report address.

Order matters during a move. Create the mailboxes and let the migration from Google Workspace or Microsoft 365 finish syncing first — that's included in the price and we do it for you. Lower the TTL on the MX record to 300 seconds a day before the cutover. Switch MX last. Expect a period where mail lands in both places while resolvers catch up; that's normal, not a fault.

An honest warning about deliverability: a domain that starts sending from new infrastructure has no track record with receiving providers yet. Run DMARC with p=none for a couple of weeks, read the reports, then tighten to p=quarantine and later p=reject. Don't send a big blast on day one — that builds a bad start that takes weeks to work off. If DNS is hosted with another provider that's fine, but then propagation and changes are their domain, not ours.

For a domain transfer to us, the domain needs to be unlocked at the current registrar and you need the auth code. A .se transfer normally takes around five days. DNS can be managed in the interface or as code with octoDNS if you'd rather version-control the zone.

• MX: values from the console, priority 10, old records removed
• SPF: a single TXT record at the root, all legitimate senders included, ending with -all
• DKIM: the record and selector shown by the console, per domain
• DMARC: TXT at _dmarc, start with p=none and a rua address you actually read
• TTL 300 before the cutover, back to normal afterward

The git import brings along history, issues and pull requests. You provide the repo URL and an access token to the source, and can choose mirroring if you want to keep the old location as a read-only copy during the transition. Build minutes aren't metered — CI runs on your plan. After the switch, update the remote with git remote set-url and repoint webhooks and deploy flows.

Be honest with yourself about the CI move. Simple workflows run as-is under act_runner, but steps that call the source platform's own API, marketplace actions that assume that platform, and OIDC federation with third parties need to be rewritten. Expect half a day to a full day for a normal pipeline, more if it's built with a lot of off-the-shelf actions.

Monitoring gets you going in a few minutes: set up checks against your URLs, TCP ports, certificates and cron jobs, connect alerts to email, Slack, Telegram or a webhook, and turn on a public status page if you want to show customers the state. Ten checks are free with no time limit and no card details.

The AI gateway exposes an OpenAI-compatible API. Create a virtual key per project, set a budget cap, and repoint the base URL in your client — the code otherwise doesn't need to change. The provider keys sit in the gateway, not in the application, which is also the point: you can switch model without touching the code and see every call in the trace view. If you want to keep traffic within the EU, route it to models running on our own fleet, but be aware that the open models aren't a drop-in substitute for the largest proprietary ones on every task — test against your own evaluation before switching in production.

• Import the repo with a token, run mirroring during the transition period
• git remote set-url origin, update webhooks and deploy keys
• Package registries for npm and Docker are included — repoint .npmrc and docker login
• Monitoring: 10 checks free, alerts to Slack or webhook
• AI gateway: one virtual key and one budget cap per project

Almost every ticket we get on day one comes down to the same handful of things, and most can be solved right away. Before you write to us: check that DNS actually points where you think it does (dig +short), that the app is listening on 0.0.0.0 and the right port, and that the SDK has both region and path-style set for object storage.

If you need us, the support form is in the console on every resource — a ticket from there brings along which resource it concerns, saving a round of questions. You can also reply directly to the order confirmation. Response times and commitments are in the SLA terms; we don't repeat them here to avoid having two versions of the same promise. Platform incidents are published on the status page, and for migrations bigger than an afternoon's work, you can order help as an engagement instead of fighting through it alone.

One thing worth knowing from the start: SIAX doesn't have ISO 27001, SOC 2 or PCI-DSS. What we do have is GDPR compliance with a data processing agreement, all data in the EU, and an open-source stack you can audit and leave. If your procurement requires a certificate, we're not the right provider today, and it's better you know that before the migration than after.

• No login email: check spam, request a new link — the old one is single-use and short-lived
• Certificate not issued: DNS doesn't point correctly yet, or a proxy is in front during validation
• 502 after a successful build: the app is listening on localhost or a hardcoded port instead of PORT
• Postgres refuses the connection: sslmode is missing, or you're trying to reach it from outside without having opened it up for that
• S3 calls fail: region field empty or virtual-host style instead of path-style
• Email lands in spam: SPF, DKIM and DMARC are in place but the domain doesn't have sending history yet