Multi-Project Platforms Quickstart

Let's explore integrating user generated sites with Vercel, providing a system for creating preview environments for your customers. The integration involves project creation, deployment management, domain aliasing (with custom suffixes), and SSO protection to secure all deployments.

Vercel's API endpoints handle project creation, deployment configuration, domain assignment, and security settings, enabling a seamless experience for your users to access and share their generated sites.

The integration would involve the following integrations:

1. Creating a Project for each chat
2. Deploying each version of the Artifact to the Project on demand when the user wants to "Publish"
3. Auto-aliasing the *.CUSTOM_SUFFIX.com domain that you want, or a user provided domain.
4. Optional Protecting all the deployments through a central proxy
5. Optional Configuring the sites as subpaths on a single domain

• We recommend one project per user chat, the user can subsequently deploy multiple versions of the artifact to the same project (while still allowing all versions to stay active). The project becomes the organizational primitive for a single chat however
• Create a project for each chat
  • Configure the name of the project to help yourself come back to it and keep your Vercel account organized.
• Most common options to customize the behaviour of each tenant project:
  • framework: The framework the application is using (ie. Next.js, React ect.)
  • serverlessFunctionRegion: The region any of your compute runs in. (It will default to iad1 if not)
  • passwordProtection: Configure a password customers can use to protect their generations

async function createProject() {
  const result = await vercel.projects.createProject({
    teamId: 'team_1a2b3c4d5e6f7g8h9i0j1k2l',
    slug: 'my-team-url-slug',
    requestBody: {
      name: 'a-project-name',
    },
  });
 
  console.log(result);
}

• Every project has one "Production" domain that points to the most recent version (while keeping previous versions) and infinite "Preview" deployments, for most applications it makes most sense to always deploy the version as a new "Production" deployment under the same project
• Create a new Deployment with this endpoint
• Most common options to customize the behaviour of each tenant project:
  • files: The set of AI Generated files you want to deploy
  • target: preview or production. Both are the same underlying infrastructure but this is a semantic identifier you can add

Leverage our pre-configured file deploy action:

npx @vercel/platforms@latest add deploy-files

The command copies the action's source into your project so you can edit it. As installed, deployFiles takes an optional { deploymentName, config, domain } object, deploys a hardcoded sample index.html file, and reads the target project from the DEPLOY_FILES_PROJECT_ID environment variable. It also imports a Vercel SDK client from ../lib/vercel, which you create yourself. See Set up the Vercel client.

To deploy your users' generated files, edit the action to accept a files argument, then call it:

import { deployFiles } from '@/actions/deploy-files';
 
// Requires the files argument added in "Deploy your own files"
await deployFiles({
  files: [
    {
      file: 'index.html',
      data: '<html><body><h1>Hello from my platform!</h1></body></html>',
    },
  ],
  deploymentName: 'customer-deployment-1',
  config: {
    framework: null, // Static HTML, no build step
  },
  domain: 'customer-site.com',
});

• If you want deployments to have a custom suffix: *.CUSTOM_SUFFIX.com, you can:
  • Setup a wildcard domain for your domain
  • Use either of these to auto-assign the *.CUSTOM_SUFFIX.com domain:
    • Assign a single domain that maps to the most recent production domain of the Project
    • Alias a specific URL to only that one deployment in a project
  • Alternatively allow customers to bring in a domain they own elsewhere to assign to their sites
• If tenants run their own code on these subdomains, submit CUSTOM_SUFFIX.com to the Public Suffix List so browsers isolate cookies between tenants for improved security. Follow the steps for protecting tenant subdomains with the Public Suffix List.

1. Create a Proxy site hosted in Vercel that all traffic will flow through that:
   1. Checks x.ai SSO and asks the user to log in if not
   2. Proxies back to the actual deployed application once authenticated
   3. Includes a Deployment Bypass header, that will lock down direct access to the Vercel applications
2. Alias all domains to the proxy site instead so all traffic goes to it first
3. Ensure ssoProtection is configured to all when creating the project to lock down access
   1. Configuring a bypass option on the deployment so the Proxy can still access it: /docs/rest-api/reference/endpoints/projects/update-protection-bypass-for-automation

• To ensure all these deployments can only be accessed as subpaths domain.com/customer_a you would first configure the same Proxy setup as in 4. (with or without authentication, depending on your product requirements.)
• This proxy would be assigned the domain you want to share in it's Vercel project
• You can then create a routing middleware in the Proxy, to be able to rewrite the paths to the domains they are hosted in Vercel.
  • It can dynamically pull the data from your backend or you can make it faster by caching it in Global Config