# Kivo --- > A SaaS theme for software, AI, API, and dev tool startups: 4 homepages and about 38 page designs, including pricing, docs landing, changelog, and integrations. --- # Kivo Source: https://kivo-astro.pages.dev/ > Deploy web apps, APIs, workers, and AI agents on a developer cloud with scaling, networking, and observability built in. --- # Pricing Source: https://kivo-astro.pages.dev/pricing/ > Simple, usage-based pricing. Start free and scale your services, databases, and workers as you grow. ## Simple pricing that grows with you Pay per second for the compute you use, with clear limits and no hidden bandwidth fees. ### Starter: $0 / month For personal projects and prototypes. - Free static sites - One free web service - Community support ### Team: $25 / month (Yearly: $20 / month) For teams shipping production apps. - Unlimited services - Preview environments - Autoscaling - Email support ### Enterprise: Custom For organizations with advanced needs. - SSO and audit logs - Dedicated support - Compliance reviews - Custom contracts ## Every feature, side by side ### Deploys | Features | Starter | Team | Enterprise | | --- | --- | --- | --- | | Static sites | Unlimited | Unlimited | Unlimited | | Web services | 1 | Unlimited | Unlimited | | Build minutes per month | 500 | 5,000 | Custom | | Zero-downtime deploys | ✓ | ✓ | ✓ | | Preview environments | — | ✓ | ✓ | | Rollback history | 7 days | 30 days | 1 year | ### Scaling and networking | Features | Starter | Team | Enterprise | | --- | --- | --- | --- | | Autoscaling | — | ✓ | ✓ | | Custom domains | 2 | Unlimited | Unlimited | | Managed TLS certificates | ✓ | ✓ | ✓ | | Private networking | — | ✓ | ✓ | | Regions | 1 | All | All | ### Workspace and security | Features | Starter | Team | Enterprise | | --- | --- | --- | --- | | Workspace members | 1 | Unlimited | Unlimited | | Role-based access | — | ✓ | ✓ | | SSO | — | — | ✓ | | Audit logs | — | — | ✓ | | Compliance reviews | — | — | ✓ | ### Support | Features | Starter | Team | Enterprise | | --- | --- | --- | --- | | Community support | ✓ | ✓ | ✓ | | Email support | — | ✓ | ✓ | | Uptime SLA | — | 99.9% | 99.99% | | Dedicated support | — | — | ✓ | | Custom contracts | — | — | ✓ | --- # FAQ Source: https://kivo-astro.pages.dev/faq/ > Answers about plans, supported languages, autoscaling, migrations, data residency, and uptime. ## Is there a free plan? Yes. The Starter plan includes free static sites and one web service, which is enough for personal projects and prototypes. ## Which languages and frameworks are supported? Node.js, Python, Go, Ruby, Rust, Elixir, PHP, and anything you can put in a container. We detect most frameworks automatically. ## How does autoscaling work? Set a minimum and maximum instance count. We add or remove instances based on CPU and memory so you only pay for what runs. ## Can I migrate from another cloud? Most teams migrate in a day. Import your repository, recreate environment variables, and restore your database from a dump. ## Where is my data stored? In the region you choose for each service and database. Backups are encrypted and stay in the same region. ## Do you offer an uptime guarantee? Team and Enterprise plans include a service level agreement with credits if we miss our availability target. --- # Documentation Source: https://kivo-astro.pages.dev/docs/ > Developer documentation: quickstarts for popular frameworks, deploy and database guides, CLI commands, and the REST API reference. --- # Security Source: https://kivo-astro.pages.dev/security/ > Certifications, encryption, access controls, monitoring, and how to report a vulnerability. Everything your security review needs in one place. --- # About Source: https://kivo-astro.pages.dev/about/ > The team behind the platform: why we started, how we build, who backs us, and the roles we are hiring for. --- # Community Source: https://kivo-astro.pages.dev/community/ > Join the community chat, forum, and GitHub. Browse the open-source CLI and SDKs, join office hours and meetups, and meet the contributors. --- # Contact sales Source: https://kivo-astro.pages.dev/contact/ > Talk to sales about volume pricing, dedicated regions, SSO, compliance reviews, and migration help for your team. --- # Autoscaling Source: https://kivo-astro.pages.dev/services/service-01/ > Add and remove instances automatically as traffic, CPU, and memory change. ## When to use autoscaling Autoscaling fits any service with traffic that changes over the day: storefronts, public APIs, webhooks, and AI endpoints that see bursts after a launch or a campaign. You pay for the instances you run, so a quiet night costs less than a busy afternoon. ## What scales and what stays fixed Web services and private services scale horizontally. Each new instance runs the same build and joins the same private network, so there is nothing to reconfigure. Background workers can scale on queue depth, and databases scale separately with their own plans. - Horizontal scaling for web and private services - Queue-based scaling for background workers - Independent limits for every environment ## Keeping costs predictable Your maximum instance count is a hard ceiling. When a service reaches it, you get an alert and the service keeps running at that size. Usage is billed per second, and the usage page shows exactly when each instance started and stopped. --- # Private networking Source: https://kivo-astro.pages.dev/services/service-02/ > Connect services, databases, and workers over an isolated network with no public exposure. ## Why it matters Most of the traffic in a modern app never needs to leave your infrastructure. An API talks to its database, a worker reads from a queue, and a frontend calls a backend. A private network keeps that traffic off the public internet, which removes a whole class of attack surface and makes every request faster. ## What you get Every workspace has one private network per region and environment. Services join it automatically when they deploy, and they are reachable by a stable hostname that does not change between releases. - Encrypted traffic between services - Internal DNS for every service and database - Public ingress only where you enable it ## Connecting from outside When you need to reach a private service from your laptop, open a short-lived tunnel with the CLI. Tunnels are tied to your account, logged in the audit log, and close automatically when you disconnect. --- # Preview environments Source: https://kivo-astro.pages.dev/services/service-03/ > Get a full copy of your stack for every pull request, then tear it down on merge. ## Why previews change code review Reading a diff tells you what changed. Clicking through a running copy tells you whether it works. Preview environments give designers, product managers, and QA the same view the end user will get, before anything reaches production. ## What gets copied Previews are created from the same config file as production, so the architecture always matches. You decide which services take part and how big they should be. - Every web service, worker, and cron job in your config - Databases created fresh, seeded, or restored from a snapshot - Environment variables from a dedicated preview group ## Keeping costs low Preview copies can run on smaller plans than production, and they stop automatically when the pull request closes or after the expiry you set. You pay per second only while a preview is running. --- # Zero-downtime deploys Source: https://kivo-astro.pages.dev/services/service-04/ > Roll out new versions behind health checks and roll back in one click. ## Why deploys break, and how we avoid it Most outages during a release come from the gap between stopping the old version and starting the new one, or from a new version that starts but cannot serve requests. Zero-downtime deploys close that gap: the old version keeps serving until the new one proves it is healthy. ## What happens on every deploy You do not need to configure anything to get safe rollouts. A default health check runs against every web service, and you can point it at your own endpoint for a stricter check. - New instances start before old ones stop - Traffic shifts only after health checks pass - Failed deploys never receive traffic ## Rolling back Every successful build is kept as a rollback target. Rolling back routes traffic to an existing image, so it takes seconds instead of a full rebuild. Database migrations are not reversed automatically, so keep them backward compatible. --- # Infrastructure as code Source: https://kivo-astro.pages.dev/services/service-05/ > Describe services, databases, and environments in one versioned config file. ## Why keep infrastructure in your repository Settings that live only in a dashboard are hard to review, hard to copy, and easy to lose. With your stack in a config file, every change goes through the same pull request process as your code, and a new environment is one command away. ## What the file can describe The config covers everything the platform runs for you. Anything you can set in the dashboard has a matching field in the file. - Web services, private services, workers, and cron jobs - Managed Postgres and in-memory caches - Variable sets, domains, and scaling rules ## Working with the dashboard You can still make quick changes in the dashboard. When the live stack drifts from the file, you see a warning and can either update the file or let the next sync reset the change. --- # CLI and API Source: https://kivo-astro.pages.dev/services/service-06/ > Script deploys, logs, and scaling from your terminal or any CI pipeline. ## Built for automation Clicking through a dashboard is fine for a first deploy. After that, most teams want deploys to follow tests, environments to be created by scripts, and on-call engineers to check logs without leaving the terminal. The CLI and API make that possible without extra tooling. ## What you can automate Every action in the dashboard is available through the API, and the CLI wraps the most common ones in short commands. - Deploys, rollbacks, and promotions between environments - Scaling rules, environment variables, and domains - Logs, metrics, and shell access for debugging ## Keys and permissions API keys are scoped to a workspace and can be limited to read-only access or to specific services. Every call made with a key is recorded in the audit log with the key name, so automated changes are as traceable as manual ones. --- # Webhooks Source: https://kivo-astro.pages.dev/services/service-11/ > Send deploy, scaling, and incident events to your own endpoints, signed and retried. ## Event types Events are named `resource.action`, so one endpoint can follow a whole area of the platform. The most used ones are `deploy.succeeded`, `deploy.failed`, `service.scaled`, and `incident.opened`. Each payload includes the workspace, the service, and a link back to the dashboard. ## Verifying signatures Every request includes a `Webhook-Signature` header: a timestamp and an HMAC of the raw body, made with the endpoint secret. Compare it with your own HMAC and reject requests older than five minutes to block replays. ## Retries and ordering A delivery succeeds when your endpoint answers with a 2xx status within ten seconds. Anything else is retried with backoff for 24 hours. Events can arrive out of order, so use the `created_at` field and the event id rather than arrival time. --- # Secrets and environment variables Source: https://kivo-astro.pages.dev/services/service-12/ > Keep keys, tokens, and settings out of your code, encrypted and scoped to each environment. ## How configuration reaches your code Every service reads its settings from environment variables at start time. The platform builds that list from three places, in order: shared groups, values set on the service, and values linked from other resources such as databases. A later value replaces an earlier one with the same key, so a service can override a group without changing it for everyone. ## Variables and secrets Both are stored the same way, encrypted at rest, and injected into the service the same way. The difference is who can read them back. ### Plain variables Use plain variables for settings that are safe to show to anyone on the team: log levels, feature flags, public URLs. Their values appear in the dashboard and in the CLI output. ### Secrets Use secrets for anything that grants access: API tokens, signing keys, passwords. Once saved, a secret value is never shown again. You can replace it or delete it, and every change is written to the audit log. ## Shared groups A group is a named set of variables that several services use. Change a value in the group and every linked service picks it up on its next deploy. - One group per concern, such as `shared-config` or `payments` - Groups can be limited to some environments - A service can link several groups ## Environments and previews Each environment has its own values. Production, staging, and preview environments never share secrets unless you link the same group to them. Preview environments copy the staging values by default, so a pull request never sees production credentials. ## Rotating a secret Rotation is a two-step change so nothing breaks in between: 1. Add the new value under a second key and deploy the code that reads it. 2. Remove the old key once nothing uses it. ```yaml title="stack.yaml" envVars: - key: API_TOKEN_NEXT sync: false ``` ## Limits A service can hold up to 500 variables, and a single value can be up to 32 KB. For larger files, such as certificates, store them as secret files and read them from disk. --- # Metrics and logs Source: https://kivo-astro.pages.dev/services/service-13/ > See latency, errors, and every log line for every service in one dashboard, with alerts that reach the right person. ## Built in, not bolted on Every service sends metrics and logs to the platform from its first deploy. There is nothing to install and no sampling to configure. When you need longer retention or your own tools, forward logs to any syslog or HTTP endpoint. ## From alert to fix An alert links straight to the metric that fired, the logs from that minute, and the deploy that was live. Most incidents end with a rollback from the same screen. --- # Ship AI apps without the GPU ops Source: https://kivo-astro.pages.dev/solutions/ai-apps/ > Deploy AI agents, inference APIs, and RAG pipelines with durable background jobs, private networking, and autoscaling built in. --- # Launch this week, scale next year Source: https://kivo-astro.pages.dev/solutions/startups/ > Deploy on push, get preview environments for every pull request, and scale without an ops hire. Free to start, with credits for early-stage teams. --- # Every client project, one calm workflow Source: https://kivo-astro.pages.dev/solutions/agencies/ > Run client sites and apps in separate workspaces, share preview environments for client review, and transfer projects at launch. --- # Platform speed with enterprise controls Source: https://kivo-astro.pages.dev/solutions/enterprises/ > Self-service deploys for large engineering teams, with single sign-on, audit logs, private networking, compliance controls, and dedicated support. --- # Branchyard Source: https://kivo-astro.pages.dev/integrations/branchyard/ > Build from self-hosted Branchyard servers, including private networks. ## Overview Branchyard runs on your own servers. The integration connects through a signed webhook and a read-only deploy key, so builds start on push without opening your network to the internet. ## What you can do - Signed webhooks with automatic key rotation - Read-only deploy keys scoped to one repository - Works with private and air-gapped instances ## Set up 1. Add your Branchyard server URL in **Integrations → Branchyard**. 2. Copy the webhook URL and secret into your Branchyard project settings. 3. Add the generated deploy key to the repository. ```shell title="Terminal" $ cloud integrations add branchyard --url https://git.internal.example ``` --- # Cachefront Source: https://kivo-astro.pages.dev/integrations/cachefront/ > Low-latency key-value cache over private networking. ## Overview Cachefront runs next to your services and is reachable only over private networking. Use it for sessions, rate limits, and hot query results without adding a public endpoint. ## What you can do - Private networking only, no public endpoint - Same region as your services - Metrics in your service dashboard ## Set up 1. Create a cache in **Integrations → Cachefront**. 2. Choose the services allowed to connect. 3. Read `CACHE_URL` from your environment. ```shell title="Terminal" $ cloud integrations add cachefront --plan small --services api,worker ``` --- # Channelbot Source: https://kivo-astro.pages.dev/integrations/channelbot/ > Post deploys, alerts, and previews to your team chat. ## Overview Channelbot posts a message when a deploy starts, succeeds, or fails, with a link to the logs. Preview environments are announced in the pull request thread so reviewers can open them right away. ## What you can do - Deploy and alert messages per channel - Preview links in pull request threads - Roll back from a message button ## Set up 1. Install Channelbot in your chat workspace. 2. Connect it in **Integrations → Channelbot**. 3. Choose a channel for each service. ```shell title="Terminal" $ cloud integrations add channelbot --channel deploys --services web,api ``` --- # Commitline Source: https://kivo-astro.pages.dev/integrations/commitline/ > Deploy on every push and open a preview environment for every pull request. ## Overview Connect a Commitline repository and the platform builds and deploys each push to your production branch. Pull requests get their own preview environment, and the deploy status is posted back as a commit check. ## What you can do - Deploy on push to any branch you choose - Preview environments for every pull request - Deploy status and logs linked from each commit check ## Set up 1. Open **Workspace settings → Integrations** and choose Commitline. 2. Authorize access to the repositories you want to deploy. 3. Link a repository to a service from the CLI or the dashboard. ```shell title="Terminal" $ cloud link --repo commitline:acme/web-frontend --branch main ``` --- # Directory Sync Source: https://kivo-astro.pages.dev/integrations/directory-sync/ > Provision and remove members automatically with SCIM. ## Overview Directory Sync keeps workspace members in step with your company directory. New hires get access on day one, and access is removed as soon as someone leaves. ## What you can do - SCIM 2.0 provisioning and removal - Groups synced to roles - Every change in the audit log ## Set up 1. Generate a SCIM token in **Security → Directory Sync**. 2. Add the endpoint and token to your directory. 3. Assign the groups that should have access. ```shell title="Terminal" $ cloud scim token create --name company-directory ``` --- # Embedstore Source: https://kivo-astro.pages.dev/integrations/embedstore/ > Store and query vector embeddings for search and AI features. ## Overview Embedstore keeps vector embeddings next to your data and answers similarity queries over private networking. Index updates run as background jobs, so your API stays fast. ## What you can do - Similarity search over private networking - Index updates as background jobs - Collections per environment ## Set up 1. Add Embedstore in **Integrations → Embedstore**. 2. Create a collection and choose the vector size. 3. Read `EMBEDSTORE_URL` from your environment. ```shell title="Terminal" $ cloud integrations add embedstore --collection docs --dimensions 1536 ``` --- # Event Stream Source: https://kivo-astro.pages.dev/integrations/event-stream/ > Forward logs and metrics to your observability stack. ## Overview Event Stream sends service logs, deploy events, and instance metrics to any HTTPS or syslog endpoint. Filter by service and level, and batch events to keep ingest costs down. ## What you can do - Logs, metrics, and deploy events in one stream - Filters by service, environment, and level - Batching and retries with backoff ## Set up 1. Open **Integrations → Event Stream** and add a destination. 2. Choose the services and log levels to forward. 3. Send a test event to check the connection. ```shell title="Terminal" $ cloud integrations add event-stream --url https://logs.example.com/ingest --level warn ``` --- # Gatecheck CI Source: https://kivo-astro.pages.dev/integrations/gatecheck-ci/ > Hold deploys until your test pipeline passes, then promote the build. ## Overview Gatecheck CI runs your tests, and the platform waits for a green result before it deploys. Promote the exact image that passed, so what you tested is what goes live. ## What you can do - Deploy only after required checks pass - Promote the tested image instead of rebuilding - Roll back from the pipeline with one step ## Set up 1. Create an API token with the `deploys:write` scope. 2. Store it as a secret in Gatecheck CI. 3. Add the deploy step at the end of your pipeline. ```shell title="Terminal" $ cloud deploy --service api --image $CI_IMAGE --wait ``` --- # Keygate Source: https://kivo-astro.pages.dev/integrations/keygate/ > Single sign-on for your workspace with SAML or OpenID Connect. ## Overview Keygate lets members log in to the dashboard and CLI with your identity provider. Enforce SSO for the whole workspace and map groups to roles. ## What you can do - SAML 2.0 and OpenID Connect - Enforced SSO for every member - Group-to-role mapping ## Set up 1. Open **Workspace settings → Security → Keygate**. 2. Upload your identity provider metadata. 3. Test the login, then turn on enforcement. ```shell title="Terminal" $ cloud sso configure --provider keygate --metadata ./idp-metadata.xml ``` --- # Letterbolt Source: https://kivo-astro.pages.dev/integrations/letterbolt/ > Send transactional email from your services with verified domains. ## Overview Letterbolt sends password resets, receipts, and alerts from your own domain. The integration adds DNS records for you and sets the API key as an environment variable. ## What you can do - DNS records for sending added automatically - API key set as an environment variable - Delivery events in Event Stream ## Set up 1. Connect Letterbolt in **Integrations → Letterbolt**. 2. Pick the sending domain and approve the DNS records. 3. Read `LETTERBOLT_API_KEY` from your environment. ```shell title="Terminal" $ cloud integrations add letterbolt --domain mail.example.com ``` --- # Oncall Relay Source: https://kivo-astro.pages.dev/integrations/oncall-relay/ > Page the on-call engineer when a deploy fails or a service goes down. ## Overview Oncall Relay turns platform alerts into incidents. Failed deploys, failing health checks, and autoscaling limits page the right rotation, and the incident closes when the service recovers. ## What you can do - Incidents for failed deploys and health checks - Routing by service and environment - Automatic resolve on recovery ## Set up 1. Create an integration key in Oncall Relay. 2. Paste it in **Integrations → Oncall Relay**. 3. Map services to escalation policies. ```shell title="Terminal" $ cloud integrations add oncall-relay --policy backend-primary ``` --- # Rowmesh Source: https://kivo-astro.pages.dev/integrations/rowmesh/ > Attach a serverless Postgres database with branching for every preview. ## Overview Rowmesh gives each preview environment its own database branch, copied from production in seconds. The connection string is set as an environment variable and removed when the preview closes. ## What you can do - One database branch per preview environment - Connection strings set as environment variables - Branches deleted when the pull request closes ## Set up 1. Connect your Rowmesh project in **Integrations → Rowmesh**. 2. Pick the parent branch to copy for previews. 3. Redeploy the service to receive `DATABASE_URL`. ```shell title="Terminal" $ cloud integrations add rowmesh --project analytics --branch-from main ``` --- # Secretkeep Source: https://kivo-astro.pages.dev/integrations/secretkeep/ > Sync secrets from your vault into environment variables on every deploy. ## Overview Keep secrets in Secretkeep and reference them by path. At deploy time the platform reads the current values and injects them as environment variables, so nothing sensitive is stored in your repository. ## What you can do - Reference secrets by path in your service config - Values refreshed on every deploy - Access logged in your workspace audit log ## Set up 1. Create a read-only Secretkeep policy for the platform. 2. Add the policy token in **Integrations → Secretkeep**. 3. Replace plain values with `secretkeep://` references. ```shell title="Terminal" $ cloud env set DATABASE_URL=secretkeep://prod/db/url --service api ``` --- # Spanlight Source: https://kivo-astro.pages.dev/integrations/spanlight/ > Trace requests across services with OpenTelemetry. ## Overview Spanlight collects OpenTelemetry traces from every service and links them to the deploy that produced them. Find the slow span, then jump to the release that introduced it. ## What you can do - OpenTelemetry collector configured for you - Traces tagged with service and deploy - Sampling set per environment ## Set up 1. Add your Spanlight API key in **Integrations → Spanlight**. 2. Choose a sampling rate per environment. 3. Redeploy to start sending traces. ```shell title="Terminal" $ cloud integrations add spanlight --sample-rate 0.2 --env production ``` --- # How Brightlane Labs halved code review time with preview environments Source: https://kivo-astro.pages.dev/customers/brightlane-labs/ > A design tooling company gave every pull request its own live URL, so designers, PMs, and engineers review the real thing. ## The challenge Brightlane Labs builds a collaborative design tool used by product teams. Reviews happened in screenshots and screen recordings, because only engineers could run a branch locally. Feedback arrived late, often after a change had merged, and a shared staging server meant one broken branch blocked everyone else's testing. ## The solution The team turned on preview environments for the main repository. Each pull request now gets a full copy of the stack, with a seeded database branch and its own URL posted as a comment. Designers and product managers review the live build in the browser. When the pull request closes, the environment and its data are removed, so nothing lingers on the bill. ## The results Review loops that used to take days now close within an afternoon. The shared staging server is gone, and release frequency tripled because merged changes are already tested by the people who asked for them. --- # How Crestfield Digital retired 40 backup scripts Source: https://kivo-astro.pages.dev/customers/crestfield-digital/ > A media company replaced hand-written backup and restore scripts with managed Postgres and infrastructure as code. ## The challenge Crestfield Digital publishes news and podcasts for a dozen regional titles. Its small team maintained 40 shell scripts for database backups, restores, and certificate renewals, each written by someone who had since moved on. A failed restore test showed that two of the backups had been silently empty for months. ## The solution The team moved its databases to managed Postgres with point-in-time recovery and defined every service and database in a config file checked into the repository. Restores became a single CLI command that anyone on the team can run. ```shell title="Terminal" $ cloud db restore newsroom-db --to "2026-03-30 08:15" ``` ## The results All 40 scripts are gone. Every database can be restored to any point in the last week, and the team gets six hours a week back for the features their editors had been asking for. --- # How Halcyon Health passed its security review with private networking Source: https://kivo-astro.pages.dev/customers/halcyon-health/ > A healthcare scheduling company moved patient data services onto a private network and cut its audit preparation from weeks to days. ## The challenge Halcyon Health runs appointment scheduling for clinics, so its services handle patient names, contact details, and visit history. Each annual security review meant weeks of collecting firewall rules and screenshots to prove which services could reach which databases. Several internal services still had public endpoints, protected only by IP allow lists that nobody wanted to touch. ## The solution The team moved its 22 services onto a private network and removed the public endpoints from everything except the patient-facing web service. Access rules live in the same config file as the services, so every change goes through code review. Preview environments run on their own isolated networks with synthetic data, so testing never touches real patient records. ## The results The next security review took three days. Auditors read the network rules straight from the repository history, and no database is reachable from the public internet. --- # How Northstar Systems cut deploy time by 80% Source: https://kivo-astro.pages.dev/customers/northstar-systems/ > A payments team moved 40 services off hand-built VMs in one weekend and now ships to production more than a dozen times a day. ## The challenge Northstar Systems processes card payments for online merchants across Europe. Its platform had grown to 40 services running on virtual machines that a two-person ops team configured by hand. Every release went out on a Tuesday or Thursday train. A deploy took most of an afternoon, needed a maintenance window for database changes, and blocked other teams while it ran. Engineers batched changes to avoid the overhead, so each release carried more risk than the last. ## The solution The team described its services, private network, and environment variables in one `cloud.yaml` file and linked the repository with the CLI. A staging copy of the stack ran in parallel for two weeks while they compared latency and error rates. ```yaml title="cloud.yaml" services: - name: payments-api type: web healthCheckPath: /healthz scaling: { minInstances: 3, maxInstances: 12 } - name: ledger-worker type: worker ``` On cut-over weekend they switched DNS service by service. Zero-downtime deploys meant the payments API never dropped a request, and private networking kept the ledger database off the public internet. ## The results Releases now go out on every merge to `main`. Health checks gate each deploy, and a failed check rolls back automatically, so engineers stopped batching work. The ops team moved on to fraud tooling instead of patching servers. --- # How Orbit Commerce kept shipping through peak season Source: https://kivo-astro.pages.dev/customers/orbit-commerce/ > A retail platform deployed more than 100 times during its busiest week of the year without a minute of downtime. ## The challenge Orbit Commerce runs storefronts for hundreds of retail brands. Every year the team froze code for six weeks around the holidays, because a bad deploy during peak traffic could take checkout offline for every merchant at once. The freeze kept the site up, but urgent fixes waited weeks and features slipped into the new year. ## The solution Checkout, search, and inventory moved to zero-downtime deploys with health checks on every release. New instances start, pass their checks, and take traffic before old ones drain, and a failed check rolls the release back on its own. Autoscaling handles the traffic peaks in three regions, and preview environments let merchants test seasonal changes before they go live. ## The results For the first time, there was no code freeze. The team shipped 120 deploys in the busiest week of the year with no downtime, and merchants got their seasonal features on schedule. --- # How a team of four at Summit Cloud runs AI workloads at scale Source: https://kivo-astro.pages.dev/customers/summit-cloud/ > An AI startup runs inference APIs and background jobs for millions of requests a day without a dedicated ops team. ## The challenge Summit Cloud turns large document sets into searchable knowledge bases. Its first version ran on self-managed clusters, and the founding engineers spent more time on queues, scaling scripts, and certificates than on the product. As customers grew, the workload became spiky: a single upload could add hundreds of thousands of background jobs in minutes. ## The solution The team split the product into a web service for the API and workers for background jobs, both defined in one config file and deployed from the same repository. Workers scale on queue depth, and the API scales on request latency. The CLI and API let them script new customer environments, and private networking keeps the vector store reachable only from their own services. ## The results Four engineers now run the whole platform, including on-call. Large uploads finish in minutes instead of hours, and the time they used to spend on infrastructure goes into the product. --- # How VectorGrid absorbed a 50× launch spike without a single page Source: https://kivo-astro.pages.dev/customers/vectorgrid/ > An analytics platform scaled from a steady baseline to fifty times its normal traffic on launch day, then back down, with no manual steps. ## The challenge VectorGrid's dashboards are used by thousands of teams, and a public launch was expected to bring a large but unknown spike. The previous setup ran at a fixed size, so the team either paid for peak capacity all month or risked falling over on the day that mattered most. ## The solution They set scaling rules on CPU and request latency for each web service, with a minimum instance count for the morning traffic and a ceiling to cap spend. Query workers moved behind private networking so they could scale on queue depth without exposing an endpoint. Before launch, the team replayed production traffic at 60 times the normal rate against a staging copy to confirm the limits held. ## The results On launch day traffic climbed to 50 times the baseline within two hours. New instances came up in seconds, latency stayed flat, and no one was paged. By the next morning the services had scaled back down on their own, and the month's compute bill came in below the old fixed setup. --- # Platform vs DIY Kubernetes Source: https://kivo-astro.pages.dev/compare/diy-kubernetes/ > Compare the platform with running Kubernetes yourself: setup time, upgrades, autoscaling, preview environments, and the hours your team spends on operations. --- # Platform vs Legacy PaaS Source: https://kivo-astro.pages.dev/compare/legacy-paas/ > Compare the platform with an older platform-as-a-service: pricing, private networking, preview environments, autoscaling, and region choice. --- # Platform vs Traditional VPS Source: https://kivo-astro.pages.dev/compare/traditional-vps/ > Compare the platform with virtual private servers: deploys, patching, backups, scaling, and the real cost of running your own machines. --- # Introducing durable workflows Source: https://kivo-astro.pages.dev/blog/introducing-durable-workflows/ > Run multi-step jobs that survive deploys, crashes, and timeouts. Each step is checkpointed, retried, and replayable from the dashboard. Background jobs start simple and end up as a pile of queues, cron entries, and retry tables. Durable workflows replace that pile with plain code: you write the steps in order, and the platform makes sure each one runs to completion, even when a deploy or a crash interrupts it. Durable workflows are generally available today on every plan. ## How a workflow runs A workflow is a function made of named steps. When a step finishes, its result is saved as a checkpoint. If the process stops, the next run skips every finished step and continues from the last checkpoint, with the same inputs. ```ts title="workflows/send-invoices.ts" import { workflow, step } from "@cloud/workflows"; export default workflow("send-invoices", async () => { const accounts = await step("load", () => loadAccounts()); const invoices = await step("render", () => renderInvoices(accounts)); await step("send", { retries: 5, timeout: "2m" }, () => sendAll(invoices)); }); ``` Steps should be safe to retry. A good rule is to make each step write its result in one place, with an idempotency key, so a retry never sends the same invoice twice. ## Start one from your app Workflows start from an API call, a schedule, or another workflow. The call returns a run id right away, so your request handler never waits on the work itself. ```ts title="app/billing.ts" import { workflows } from "@cloud/sdk"; const run = await workflows.start("send-invoices", { month: "2026-10" }); console.log(run.id); // wf_run_8f2c... ``` ## Debug a failed run Every run has a timeline in the dashboard with the input, output, duration, and logs of each step. When a step fails after its last retry, the run pauses instead of disappearing. Fix the bug, deploy, and replay the run from the failed step. ```bash cloud workflows replay wf_run_8f2c --from send ``` ## Limits and pricing Workflows are billed as regular compute. Checkpoints and replays are included. A single run can last up to 30 days, and a step can return up to 1 MB of data. See the changelog for the full list of limits. --- # How we cut cold starts in half Source: https://kivo-astro.pages.dev/blog/cutting-cold-starts-in-half/ > A look at the snapshot cache, lazy module loading, and the routing change that brought the median cold start of a Node service from 410 ms to 190 ms. A cold start is the time between a request arriving and a fresh instance being ready to answer it. For services that scale to zero, it is the first thing users feel. Over the last quarter we brought the median cold start of a Node service from 410 ms to 190 ms. This post explains the three changes that did most of the work. ## Measure before you change anything We split every cold start into four phases and logged each one: scheduling, image pull, runtime boot, and application init. The breakdown surprised us. Image pulls were already cached on most hosts, but application init, the time your own code spends importing modules and opening connections, was almost half of the total. ```text title="cold-start breakdown (p50, before)" scheduling 38 ms image pull 52 ms runtime boot 131 ms app init 189 ms total 410 ms ``` ## Snapshot the runtime after boot The runtime boot phase does the same work for every instance of a given build. We now take a memory snapshot right after the runtime finishes booting, store it next to the build, and restore it on the next cold start. Restoring a snapshot takes about 30 ms, compared to 131 ms for a full boot. Snapshots are taken per build, so a new deploy never restores state from an old one. ## Load modules when they are first used Many services import every route handler at startup, even though one request only needs one of them. The runtime now supports lazy route modules: the router knows which file handles each path, and imports it on the first request to that path. ```ts title="server.ts" import { createServer } from "@cloud/runtime"; createServer({ routes: { "/api/invoices": () => import("./routes/invoices"), "/api/reports": () => import("./routes/reports"), }, }); ``` ## Route the first request to a warm neighbor The last change was in the router. When a new instance is starting, the first request is sent to an existing warm instance if one has capacity, and the new instance only receives traffic once it reports ready. Users no longer wait for a cold start during a scale-up, only during a scale from zero. ## Results The median cold start is now 190 ms and the p95 is 420 ms, down from 980 ms. All three changes are on by default. Lazy route modules need the runtime `2.4` or later. --- # Why deploy tokens now expire after one hour Source: https://kivo-astro.pages.dev/blog/short-lived-deploy-tokens/ > Long-lived CI tokens are the easiest credential to leak. Here is how short-lived tokens work, and how to move your pipeline to them in a few minutes. Deploy tokens used to live forever. They were created once, pasted into a CI secret, and forgotten. That made them the most common credential in our incident reports: copied into logs, left in old forks, or shared between projects. New deploy tokens now expire one hour after they are issued. Existing long-lived tokens keep working until January, and the dashboard shows which projects still use them. ## How short-lived tokens work Instead of storing a token, your CI provider proves who it is with its own identity token (OIDC). The platform checks that the identity matches a trust rule you created, then issues a deploy token that is valid for one hour and scoped to one project. ```yaml title=".ci/deploy.yml" deploy: permissions: id-token: write steps: - run: npm ci - run: npx cloud deploy --env production env: CLOUD_OIDC: "true" ``` Nothing secret is stored in the repository or the CI settings. A leaked token stops working within the hour. ## Create a trust rule A trust rule says which repository, branch, and environment may deploy to a project. Create one in **Project → Settings → Deploy access**, or from the CLI: ```bash cloud trust create \ --project web-frontend \ --repository your-org/web-frontend \ --branch main \ --env production ``` Rules are evaluated on every exchange, so removing a rule cuts access right away. ## What changes for you - Pipelines that use the official CI integration switch automatically on the next run. - Pipelines that call the API with a stored token keep working until January. After that, the stored token is rejected. - Personal access tokens for the CLI are not affected. They still expire after 90 days, as before. If your CI provider does not support OIDC yet, create a token with an explicit expiry of at most seven days and rotate it from a cron job. --- # Set up a preview environment for every pull request Source: https://kivo-astro.pages.dev/blog/preview-environments-for-every-pull-request/ > A step-by-step guide to deploying each pull request to its own URL, with its own database branch, and cleaning it up when the pull request closes. A preview environment is a full copy of your app, deployed from a pull request, at its own URL. Reviewers click a link instead of pulling the branch, and product and design can check a change before it merges. This guide sets one up in about ten minutes. ## Install the CLI You need the CLI to link the repository and to test the setup locally. ```bash title="npm" npm install -g @cloud/cli ``` ```bash title="pnpm" pnpm add -g @cloud/cli ``` ```bash title="yarn" yarn global add @cloud/cli ``` ```bash title="bun" bun add -g @cloud/cli ``` Then log in and link the project in the root of your repository: ```bash cloud login cloud link --project web-frontend ``` ## Turn on previews The project file sits in the root of the repository, next to `package.json`: - db/ - seed.sql - src/ - ... - **cloud.config.ts** previews and services - package.json Previews are configured in the project file. The `previews` block says which branches get one, which environment variables they use, and how long they live after the pull request closes. ```ts title="cloud.config.ts" import { defineConfig } from "@cloud/cli"; export default defineConfig({ service: "web-frontend", previews: { branches: ["*", "!main"], env: "preview", expireAfter: "3d", }, }); ``` Commit the file and open a pull request. The first preview builds in the same time as a normal deploy, and the bot comments the URL on the pull request. **Open the preview from the dashboard** Press ⌘ K in the dashboard and type the pull request number to jump straight to its preview. ## Give each preview its own data A preview that writes to the staging database is not really isolated. Add a database branch so every preview starts from a copy of the schema and a small seed: ```ts title="cloud.config.ts" previews: { branches: ["*", "!main"], env: "preview", database: { branchFrom: "staging", seed: "./db/seed.sql" }, }, ``` Database branches are copy-on-write, so creating one takes a few seconds, whatever the size of the parent. ## Clean up When the pull request merges or closes, the preview and its database branch are deleted after `expireAfter`. To delete one sooner, run: ```bash cloud previews delete --pr 142 ``` That is all. From now on, every pull request gets a link, and nothing is left running after it closes. --- # Zero-downtime database migrations in five steps Source: https://kivo-astro.pages.dev/blog/zero-downtime-database-migrations/ > Renaming a column while the app is serving traffic is safe if you split the change into small, backward-compatible deploys. Here is the pattern we use. Most migration outages come from the same mistake: the schema and the code change in one deploy. For a few seconds, old instances run against the new schema, or new instances run against the old one, and queries fail. The fix is to never let the two depend on each other at the same time. As an example, we will rename `users.name` to `users.full_name` on a busy table. ## Add the new column Add the column as nullable, with no default that would rewrite the table. This is fast and does not lock writes. ```sql title="migrations/001_add_full_name.sql" ALTER TABLE users ADD COLUMN full_name text; ``` ## Write to both columns Deploy code that writes every change to both `name` and `full_name`, but still reads from `name`. Old and new instances can run side by side, because the old ones never read `full_name`. ## Backfill in batches Copy the existing rows in small batches, so the backfill never holds a long lock or fills the write-ahead log. ```sql title="migrations/002_backfill_full_name.sql" UPDATE users SET full_name = name WHERE id IN ( SELECT id FROM users WHERE full_name IS NULL LIMIT 5000 ); ``` Run it in a loop until it updates zero rows. A durable workflow is a good fit for this, because it can pause and resume between batches. ## Read from the new column Once the backfill is done and both columns match, deploy code that reads from `full_name`. Keep writing to both for one more deploy, so you can roll back without losing data. ## Drop the old column When no running instance reads or writes `name`, stop writing to it, deploy, and then drop it. **Do not drop the column in the same deploy** Instances that are still draining run the previous release. If the column is gone before they stop, their queries fail. ```sql title="migrations/003_drop_name.sql" ALTER TABLE users DROP COLUMN name; ``` ## The rule behind the steps Every deploy must work with the schema before it and the schema after it. If you keep that rule, the order of deploys and migrations no longer matters, and a rollback is always one click away. --- # Set cost alerts before the surprise bill Source: https://kivo-astro.pages.dev/blog/set-cost-alerts-before-the-surprise-bill/ > Budgets, per-service alerts, and spend caps: a short guide to knowing what you will pay before the invoice arrives. Usage-based pricing is fair, but only if you can see the usage. A runaway job, a missing cache, or a traffic spike can double a bill in a weekend. This guide sets up three layers of protection in about fifteen minutes. ## Set a monthly budget A budget is the amount you expect to spend in a month. It does not stop anything; it gives every alert a reference point. Set it in **Billing → Budget**, or from the CLI: ```bash cloud billing budget set --amount 400 --currency USD ``` The dashboard then shows your forecast for the month next to the budget, based on your usage so far. ## Alert on the forecast, not the total An alert on the total spend fires when the money is already gone. An alert on the forecast fires as soon as the trend changes, often days earlier. ```yaml title="cloud.alerts.yml" alerts: - name: forecast-over-budget when: forecast > budget * 1.1 notify: ["#ops", "billing@example.com"] - name: daily-spike when: spend_today > spend_7d_avg * 2 notify: ["#ops"] ``` Apply the file with `cloud alerts apply`. Alerts can notify a chat channel, an email address, or a webhook. ## Find the service behind a spike When an alert fires, open **Billing → Usage** and group by service. Each service shows its compute, bandwidth, and storage for the day, so a spike usually points to one line. From there, the service metrics show whether it came from more traffic or from more work per request. ## Cap what can run away Some resources can grow without limit: autoscaling services, background workers, and build minutes. Give them a ceiling: ```ts title="cloud.config.ts" export default defineConfig({ service: "image-worker", instances: { min: 0, max: 20 }, spendCap: { monthly: 150, action: "scale-to-min" }, }); ``` When the cap is reached, the service scales to its minimum instead of growing further, and the alert tells you why. Raise the cap from the dashboard if the growth was expected. With a budget, forecast alerts, and caps in place, the invoice becomes a confirmation of what you already know. --- # Durable workflows are generally available Source: https://kivo-astro.pages.dev/changelog/2026-10-durable-workflows/ > Run background jobs with retries, timeouts, and step-level logs. Workflows let you split a long job into steps that survive restarts, deploys, and crashes. Each step is checkpointed, so a failure retries that step instead of the whole run. ## What's included - **Retries with backoff** per step, with a maximum attempt count - **Timeouts** per step and per run - **Step-level logs** in the dashboard and through `cloud logs --workflow` - **Manual replay** from any failed step ## Get started ```ts import { workflow, step } from "@cloud/workflows"; export default workflow("send-invoices", async () => { const accounts = await step("load", () => loadAccounts()); await step("send", { retries: 5, timeout: "2m" }, () => sendAll(accounts)); }); ``` Workflows are billed as regular compute. There is no extra charge for checkpoints. --- # Short-lived deploy tokens by default Source: https://kivo-astro.pages.dev/changelog/2026-09-short-lived-deploy-tokens/ > CI tokens now expire after one hour and are scoped to a single project. New deploy tokens created from the dashboard or the CLI now expire after one hour and can only deploy the project they were created for. ## What changes - `cloud tokens create` issues a one-hour token unless you pass `--ttl` - Tokens are scoped to one project and one environment - Existing long-lived tokens keep working until **Jan 2027** ## What to do If your CI stores a long-lived token, switch to OIDC tokens issued by your CI provider, or create a new token in each pipeline run: ```bash cloud tokens create --project web-frontend --env production --ttl 1h ``` --- # Faster builds with layer caching Source: https://kivo-astro.pages.dev/changelog/2026-09-build-layer-caching/ > Repeat builds are up to three times faster for Node and Python. Builds now reuse dependency layers when your lockfile has not changed. Most projects see repeat builds finish two to three times faster. ## Details - Works with `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `poetry.lock`, and `requirements.txt` - The cache is kept per branch, so preview builds do not evict production layers - Clear it from **Settings → Build** or with `cloud build --no-cache` No configuration is needed. Caching is on for every project. --- # Log streaming no longer drops lines under load Source: https://kivo-astro.pages.dev/changelog/2026-09-log-streaming-fix/ > High-volume services now stream every line to the dashboard and the CLI. Services writing more than 5,000 lines per second could lose lines in live tail. The log router now applies backpressure instead of dropping, and the CLI resumes from the last received line after a reconnect. ## Also fixed - Multi-line stack traces are grouped into a single entry again - `cloud logs --since` respects the timezone set in your profile --- # Read replicas for Postgres Source: https://kivo-astro.pages.dev/changelog/2026-08-postgres-read-replicas/ > Add replicas in one click to scale read-heavy workloads. Managed Postgres now supports up to five read replicas per database, in the same region or in another one. ## How it works - Replicas stream changes from the primary with typical lag under 100 ms - Each replica gets its own connection string: `DATABASE_REPLICA_URL_1`, `_2`, and so on - Promote a replica to primary during a regional incident ```bash cloud postgres replicas add orders-db --region eu-west ``` Replicas are billed at the same rate as the primary instance size. --- # Preview environments can start from a database snapshot Source: https://kivo-astro.pages.dev/changelog/2026-08-preview-database-snapshots/ > Seed every pull request with realistic data instead of an empty schema. Preview environments can now restore a nightly snapshot of a source database when they start. Pair it with a masking script to keep personal data out of previews. ## Configure it ```yaml previews: database: from: orders-db snapshot: nightly mask: ./scripts/mask.sql ``` Snapshots are restored in parallel with the build, so previews do not take longer to come up. --- # Smoother zero-downtime deploys Source: https://kivo-astro.pages.dev/changelog/2026-07-zero-downtime-deploys/ > Old instances now drain open connections before they stop. Long-lived connections could be cut when an old instance stopped during a deploy. Instances now leave the load balancer first, finish in-flight requests for up to 30 seconds, then stop. Set a different drain window per service: ```toml [deploy] drain_timeout = "60s" ``` --- # Cron jobs with timezones and overlap control Source: https://kivo-astro.pages.dev/changelog/2026-07-cron-timezones/ > Schedule jobs in local time and decide what happens when a run is still going. Cron jobs accept a timezone and an overlap policy. ## Options - `timezone`: any IANA name, for example `Europe/Paris`. Daylight saving changes are handled for you. - `overlap`: `skip` the new run, `queue` it, or `replace` the running one ```toml [[cron]] name = "nightly-report" schedule = "0 2 * * *" timezone = "Europe/Paris" overlap = "skip" ``` --- # Node 22 is the default runtime, Node 18 is deprecated Source: https://kivo-astro.pages.dev/changelog/2026-06-node-22-default/ > New services start on Node 22. Node 18 builds stop on Dec 1, 2026. New Node services now build on Node 22 LTS. Existing services keep their current version until you change it. ## Timeline - **Now**: Node 22 is the default; Node 18 shows a warning in build logs - **Dec 1, 2026**: new builds on Node 18 are rejected - Running services are never stopped Pin a version in `package.json`: ```json { "engines": { "node": "22.x" } } ``` --- # Export audit logs to your own storage Source: https://kivo-astro.pages.dev/changelog/2026-06-audit-log-export/ > Stream every workspace and project event to an S3-compatible bucket. Audit logs can now be exported continuously to any S3-compatible bucket you own, for long-term retention or for your SIEM. ## What is exported - Logins, token creation, and role changes - Deploys, rollbacks, and environment variable changes - One JSON object per line, delivered within one minute Turn it on in **Workspace settings → Audit log → Export**. --- # Cookie Policy Source: https://kivo-astro.pages.dev/cookie-policy/ > Which cookies and similar technologies this website uses, why it uses them, and how to control them. This Cookie Policy explains how we use cookies and similar technologies when you visit this website or sign in to the dashboard. Read it together with our [Privacy Policy](https://kivo-astro.pages.dev/privacy-policy/). ## What Are Cookies Cookies are small text files that a website stores in your browser. They let the site remember your session, your preferences, and how you use it. Similar technologies, such as local storage and pixels, work the same way and are covered by this policy. ## Cookies We Use We group cookies by purpose: - **Strictly necessary:** Keep you signed in, protect forms against abuse, and balance traffic across regions. The site does not work without them. - **Preferences:** Remember choices such as language and light or dark mode. - **Analytics:** Count visits and measure which pages load slowly, using aggregated data. - **Marketing:** Measure sign-ups from campaigns. These are off until you accept them. ## Cookie Details | Cookie | Purpose | Type | Duration | | ---------------- | ----------------------------------------- | ----------- | -------- | | `session_id` | Keeps you signed in to the dashboard | Necessary | Session | | `csrf_token` | Protects forms from cross-site requests | Necessary | Session | | `theme` | Stores your light or dark mode choice | Preferences | 1 year | | `locale` | Stores your language | Preferences | 1 year | | `analytics_id` | Counts unique visits, without your name | Analytics | 13 months| | `campaign_ref` | Attributes sign-ups to a campaign | Marketing | 90 days | ## Third-Party Cookies Some features load services from other providers, such as embedded videos, payment forms, and support chat. These providers may set their own cookies under their own policies. We only load them after you open the feature or accept the related category. ## Managing Your Preferences You can change your choice at any time: - Use the cookie settings link in the footer to accept or reject each category. - Block or delete cookies in your browser settings. Blocking strictly necessary cookies will sign you out. - Turn on the Global Privacy Control signal in your browser. We treat it as a rejection of marketing cookies. ## Changes to This Policy We may update this policy when we add or remove cookies. The date at the top of this page shows the latest version. ## Contact Us If you have questions about this Cookie Policy, please contact us through the website contact form. --- # Privacy Policy Source: https://kivo-astro.pages.dev/privacy-policy/ > Understand how personal information submitted through this website is collected, used, protected, and managed. Your privacy is important to us, and we are committed to protecting the personal information you share with us. This Privacy Policy explains how we collect, use, and safeguard your information when you visit this website. ## Information We Collect We collect two types of information from you: - **Personal Information:** - Name - Email address - Billing information (e.g., credit card details) - Any information you provide voluntarily through forms, surveys, or account creation - **Non-Personal Information:** - IP address - Browser type - Operating system - Pages visited and time spent on our site - Referring website ## How We Use Your Information We use the information we collect for the following purposes: - To provide and improve our services - To process transactions and send receipts - To send you updates, promotions, and service-related communications - To personalize your experience on our Website - To comply with legal obligations - To detect and prevent fraudulent activity ## Cookies and Tracking Technologies We use cookies and similar tracking technologies to enhance your experience on our Website. These include: - **Essential Cookies:** Required for the operation of our Website. - **Performance Cookies:** Help us understand how you use our site. - **Marketing Cookies:** Track your browsing behavior for targeted advertising. You can control cookies through your browser settings. ## Sharing of Information We do not sell, rent, or trade your personal information. However, we may share your information with: - **Service Providers:** Third-party companies that help us operate our Website and provide services. - **Legal Authorities:** When required by law or to protect our rights and property. - **Business Transfers:** In case of a merger, acquisition, or sale of assets. ## Data Security We implement industry-standard security measures to protect your data. However, no method of transmission over the Internet or electronic storage is 100% secure. While we strive to use commercially acceptable means to protect your personal information, we cannot guarantee absolute security. ## Your Rights Depending on your location, you may have the following rights regarding your personal information: - Access your data - Correct or update your data - Request deletion of your data - Restrict processing of your data - Withdraw consent for data usage To exercise your rights, please contact us through the website contact form. ## Third-Party Links Our Website may contain links to third-party websites. We are not responsible for the privacy practices of these websites. We encourage you to review their privacy policies before providing any personal information. ## Children's Privacy Our Website is not intended for individuals under the age of 13. We do not knowingly collect personal information from children under 13. If you believe we have collected such information, please contact us immediately. ## Changes to This Privacy Policy We may update this Privacy Policy from time to time. Any changes will be posted on this page with an updated "Effective Date." We encourage you to review this Privacy Policy periodically. ## Contact Us If you have any questions or concerns about this Privacy Policy, please contact us through the website contact form. Thank you for trusting us with your personal information. --- # Terms & Conditions Source: https://kivo-astro.pages.dev/terms-conditions/ > Review the terms that apply when visitors use this website, content, and contact forms. By accessing or using this website, you agree to comply with and be bound by the following Terms and Conditions ("Terms"). If you do not agree with these Terms, please do not use this website. ## Acceptance of Terms By accessing or using the Website, you confirm that you are at least 18 years old or have the legal consent of a parent or guardian. Your continued use of the Website constitutes your agreement to these Terms. ## Use of the Website You agree to use the Website only for lawful purposes and in a manner that does not infringe on the rights of others or restrict their use of the Website. Prohibited uses include but are not limited to: - Engaging in any unlawful activity. - Attempting to gain unauthorized access to the Website or its servers. - Introducing harmful software or code, such as viruses or malware. - Misrepresenting your identity or affiliations. ## User Accounts If you create an account on our Website, you are responsible for maintaining the confidentiality of your login credentials. You agree to notify us immediately of any unauthorized use of your account. We reserve the right to terminate accounts that violate these Terms. ## Intellectual Property All content on the Website, including but not limited to text, images, logos, and software, is protected by copyright, trademark, and other intellectual property laws. You may not reproduce, distribute, or modify any content without prior written consent from us. ## Purchases and Payments All purchases made on the Website are subject to our pricing and payment terms. You agree to provide accurate payment information and authorize us to charge your payment method for the agreed-upon amounts. Refunds, if applicable, will be processed according to our Refund Policy. ## Disclaimer of Warranties The Website and its content are provided "as is" without warranties of any kind, either express or implied. We do not guarantee that the Website will be error-free, secure, or available at all times. ## Limitation of Liability To the fullest extent permitted by law, we shall not be liable for any indirect, incidental, special, or consequential damages arising from your use of the Website or inability to access it. Our total liability for any claims related to the Website shall not exceed the amount paid by you, if any, to us. ## Termination We reserve the right to suspend or terminate your access to the Website at our sole discretion, without notice, if we believe you have violated these Terms or any applicable law. ## Third-Party Links Our Website may contain links to third-party websites. We are not responsible for the content or practices of these websites. Your use of third-party sites is at your own risk. ## Governing Law These Terms are governed by and construed in accordance with the laws of the State of Imaginary, USA, without regard to its conflict of law principles. Any disputes arising under these Terms shall be resolved in the courts located in Imaginary City, USA. ## Changes to Terms We reserve the right to update or modify these Terms at any time without prior notice. Any changes will be effective immediately upon posting on this page. Your continued use of the Website constitutes acceptance of the revised Terms. ## Contact Us If you have any questions or concerns about these Terms, please contact us through the website contact form. Thank you for visiting this website.