Skip to content

Website Hosting

Sprigr Team includes built-in website hosting. You can run everything from a simple landing page with an embedded agent chat widget up to a server-rendered web app or a full WordPress store, without any external hosting provider.

Agents create and manage websites for you through chat — describe what you want and they generate the code, build it, and deploy it. The portal gives you a dashboard for every site with traffic, builds, domains, environment variables, and version history.

  • Static sites — HTML, CSS, JavaScript, images, and other static assets. Covers landing pages, documentation sites, and client-side apps built into static files.
  • Framework apps with server-side rendering — Next.js, Astro, and Remix projects are built and deployed with full SSR support. See Builds and Deployments.
  • WordPress and WooCommerce stores — A managed WordPress install with WooCommerce, running in its own container. See WordPress Stores.

Every website gets a URL of the form https://{organisation-slug}-{site-slug}.sites.sprigr.com, and you can attach your own domain later (see Custom Domains).

  1. Navigate to the Websites page

    Sign in to team.sprigr.com and click Websites in the sidebar.

  2. Click “New Website”

    In the Create Website dialog, enter a name and choose a type: website, dashboard, portal, app, docs, or store. Choose store for a live WordPress + WooCommerce store, set up for you in a few seconds; the other types label the kind of site you are building. Sites of type app are owned by a marketplace app and cannot be built or rolled back from the portal.

  3. Choose visibility

    Decide whether the site is public or restricted — see access controls below. You can change this at any time.

  4. Optionally select a chat widget agent

    Pick an agent to power a chat widget on the site, so visitors can talk to it directly from the page. The picker appears once your organisation has at least one agent.

  5. Click “Create”

    A starter page is deployed automatically, so the site’s URL is live immediately. From there, ask an agent to build out the real site, or deploy your own files through a build.

How many websites you can run depends on your plan: Free 0, Starter 5, Team 25, Pro 100, Business and Enterprise unlimited. The cap is enforced when a build is admitted, not when the site is created: on the Free plan you can create a site and see its starter page, but every build (agent, CLI, or API) is refused with a QUOTA_EXCEEDED error until you upgrade. Custom domains per site are capped per plan in the same way — see Custom Domains.

Each website’s page in the portal shows its URL, storage used, deployment count, and build minutes used this month, plus panels for:

  • Traffic — request analytics (see below)
  • Builds — build history and logs
  • Domains — custom domain setup
  • Environment — environment variables and secrets
  • Activity — a timeline of deploys, errors, and configuration changes
  • Access — visibility and per-member access grants
  • Version History — every deployment, with one-click rollback

When you select an agent during creation, the starter page includes a chat widget wired to that agent. Messages from visitors are delivered to the agent through a dedicated webhook, and the agent’s replies appear in the widget. The widget’s position, welcome message, and input placeholder are configurable in the website’s settings.

You can control who can view a hosted website:

  • Public — Anyone with the link can view the site. Use this for customer-facing landing pages and help centres.
  • Internal — Only signed-in members of your Sprigr Team organisation can view the site. Use this for internal tools and documentation.
  • Private — Only the owner, admins, and members you explicitly grant access to can view the site. Manage grants from the Access panel on the website’s page.

Each hosted website includes request analytics, available from the Traffic panel over a 24-hour, 7-day, or 30-day window:

  • Requests — Total requests served, with a requests-over-time chart
  • Bandwidth — Total bytes served and average response size
  • Status codes — A breakdown of responses by HTTP status
  • Top pages — The most requested paths on your site
  • HTML edge caching — Off by default. When enabled, public pages that your framework marks as shared-cacheable are stored at the Cloudflare edge per deployment, so repeat visitors skip the site worker and its cold start. Requests carrying a cookie, non-public sites, and responses that set a cookie are never cached, so carts and sessions stay per-visitor. Today this is switched on only through the set_website_html_cache MCP tool (or by asking an agent); there is no portal toggle yet. The tool takes excludePaths for routes that render per-visitor state before a cookie exists (for example /cart or /bag) and an optional maxTtlSeconds ceiling so a content change cannot stay invisible for longer than you want. Static assets and /_next/image are cached regardless of this setting.
  • Media proxy — When the platform media proxy is enabled for your deployment, every server-rendered site gets an env.MEDIA service binding and a per-site MEDIA_TOKEN secret, so your server code can upload, fetch, and serve user-generated files (images, attachments, exports) from a platform-owned bucket prefixed by site, without bringing your own storage. Guard against env.MEDIA being undefined in code that must also run where the proxy is not configured.

Deleting a website takes it offline immediately. Its files, deployments, custom domains, and builds are permanently removed after a 30-day grace period.