page:recipes:vendor portal:sveltekit:activity history

Host vendor portal with SvelteKit: application activity history

Summary

Deploy a vendor portal built with SvelteKit on Ample using the transactional workflows pattern. Compute runs the app in an isolated microVM behind a public HTTPS URL, a managed PostgreSQL 16 database is auto-provisioned and injected as DATABASE_URL. Verified on SvelteKit: an optimistic version check and an event row written in the same transaction, a stale update rejected, and a history query over the application-owned events (history=2 conflict=rejected). Not separately tested: your domain records, validation rules and concurrency policy; treat the vendor portal-specific behavior as your application code.

Representative Queries

Resource Requirements

Infrastructure Requirements

Compute

Postgres

Framework

SvelteKit

Workload

Vendor portal

Release Status

Published

Support Status

Verified

Execution Status

Ready

Prerequisites

Tested Configuration

Input Schema

{
  "additionalProperties": false,
  "properties": {
    "env": {
      "description": "Encrypted environment variables (bucket credentials, secrets)",
      "items": {
        "pattern": "^[A-Z][A-Z0-9_]*=.*$",
        "type": "string"
      },
      "maxItems": 50,
      "type": "array"
    },
    "name": {
      "description": "App name",
      "maxLength": 63,
      "minLength": 1,
      "pattern": "^[a-z0-9-]+$",
      "type": "string"
    },
    "path": {
      "description": "Project directory or ample.toml service",
      "maxLength": 512,
      "minLength": 1,
      "type": "string"
    },
    "release_command": {
      "description": "Migration command run before activation",
      "maxLength": 512,
      "type": "string"
    }
  },
  "required": ["name", "path"],
  "type": "object"
}

Workflow Steps

  1. Build and start
    vite build with @sveltejs/adapter-node then node build on the node-22 template. The server must bind 0.0.0.0 on PORT.
  2. Implement the pattern on PostgreSQL
    The fixture's module implements transactional workflows: an optimistic version check and an event row written in the same transaction, a stale update rejected, and a history query over the application-owned events (history=2 conflict=rejected). Copy the approach into your schema; keep migrations idempotent and run them with --release-command.
  3. Deploy
    Run the synchronous deploy once and read the result (exit 0 live, 1 failed, 2 blocked). Re-running with no change is a no-op.
    ample deploy . --name <app_name> --public
  4. Verify
    Fetch the live URL and the pattern self-test route(s) (/p/transactional-workflows) from the example; then run your own checks. On failure read ample logs <app_name> --kind build then --kind runtime.
    ample logs <app_name> --kind build

Examples

SvelteKit pattern fixture

Success Checks

  1. app responds on its public URL

    • Kind: http_get
    • Path: /
    • Expect: ample canary sveltekit patterns

  2. transactional-workflows self-test

    • Kind: http_get
    • Path: /p/transactional-workflows
    • Expect: tx=ok history=2 conflict=rejected

Limitations

Cost Estimate

Evidence Summary

  1. Kind: canary_run

    • Summary: SvelteKit pattern fixture deployed on Ample; checks passed for transactional-workflows and configuration-secrets.
    • Observed At: 2026-09-20T03:31:44Z
    • Implementation Revision: 03b6402b1b3e19178985f08ea4033804521d85d4-dirty
    • Expires At: 2027-03-19T03:31:44Z
    • Scope: Checks: [/p/transactional-workflows], Pattern: pattern:transactional-workflows, Template: node-22

  2. Kind: canary_run

    • Summary: The same SvelteKit app deployed with a --release-command migration; the marker it created was readable after activation.
    • Observed At: 2026-09-20T02:16:51Z
    • Implementation Revision: 199ff1dfd52683832ae75d3f98b53a7a4bff7f96-dirty
    • Expires At: 2027-03-19T02:16:51Z
    • Scope: Pattern: pattern:transactional-workflows

Last Verified At

2026-09-20T03:31:44Z

MCP Binding

Unknowns