Customer documentation
Serverless overview
Understand the Vercel-backed Serverless hosting flow, what it supports, and how customer deployments work.
Serverless overview
Serverless sites in this portal are Vercel-backed public deployments managed for you by TSI. Use Serverless for modern frontends, static sites, documentation sites, marketing pages, dashboards, and framework apps that build cleanly from a GitHub repository or ZIP upload.
Best for
Next.js, Vite, Astro, SvelteKit, Nuxt, Remix, Gatsby, Vue, Angular, static HTML/CSS/JS, and similar build-based websites.
Not cPanel
Serverless sites do not use cPanel File Manager, cPanel email, cPanel MySQL, or cPanel document roots.
Vercel-backed
The portal creates and manages the Vercel project, uploads the source, starts the deployment, and returns the live URL.
Public output
Deployments are public by default and receive a generated .vercel.app live URL after the build starts.
No Vercel login
Customers do not need a Vercel account, Vercel dashboard access, or a Vercel token to deploy from the portal.
Custom domains
After deployment, attach a domain and copy the DNS records shown in the portal.
Vercel model in this portal
Think of the portal as the customer-friendly control panel and Vercel as the deployment engine behind it. You use the TSI portal; the portal handles the Vercel project and deployment API work.
Portal site
The site record you see in Client portal, Serverless. It stores the name, source type, build settings, logs, URL, and domains.
Vercel Project
Each serverless site maps to a managed Vercel Project behind the scenes. The project is reused for later deploys of the same site.
Production deployment
Clicking Deploy starts a Vercel production deployment. Production is the customer-facing environment for the live site.
Generated URL
A successful build receives a stable generated .vercel.app URL. Test that URL before connecting a custom domain.
Preview and development
Vercel supports Preview and Development environments too. The portal focuses on customer production deploys and stores env vars across the Vercel targets for compatibility.
Public by default
The portal creates customer sites for public web access. Do not deploy private admin tools unless they include their own authentication.
What runs on Vercel
Static assets
HTML, CSS, JavaScript, images, fonts, and exported files are served from Vercel's web infrastructure after deployment.
Framework pages
Frameworks such as Next.js, Nuxt, SvelteKit, Astro, Remix, and Gatsby can build pages using their normal Vercel-supported output.
Serverless functions
Framework API routes, server-rendered routes, middleware, and functions run on Vercel when the framework creates them. They are not cPanel PHP files.
Build step
Vercel installs dependencies and runs the build command before the site becomes live.
Custom domains
Domains attach to the managed Vercel Project. DNS must point to Vercel before the domain shows Connected.
HTTPS
Vercel handles HTTPS certificates after DNS is correct. Customers normally do not upload certificates for serverless domains.
Choose Serverless or cPanel
Choose Serverless
For modern apps built from GitHub or ZIP source, frontends that use build commands, static sites, docs sites, React/Vite apps, and framework sites.
Choose cPanel
For traditional PHP hosting, WordPress file editing, cPanel email accounts, MySQL through cPanel, phpMyAdmin, cron jobs, and File Manager workflows.
Do not mix hosts
Do not point the same domain host to cPanel and Vercel at the same time. Choose one live website target for each hostname.
No direct file edits
Serverless sites are redeployed from source. To change files, update GitHub or upload a new ZIP instead of editing a live document root.
No cPanel mailbox
Serverless does not create email mailboxes. Keep email records where your mail provider requires them.
Long-running processes
Do not use Serverless for permanent background daemons, raw VPS workloads, or apps that require direct server shell access.
Requirements and limits
Availability
Serverless unlocks after your account has an active, approved, or completed hosting order. Each customer can deploy up to 10 serverless sites.
Access
Requires an active, approved, or completed hosting order.
Site limit
Up to 10 serverless sites per customer account.
Visibility
Deployments are public by default.
Provider
Deployments are backed by Vercel and managed by the portal. You do not need your own Vercel token.
Environment
Deploy from the portal when you want the current site to become the public production deployment.
Source
Deploy from a public GitHub repository URL or from a ZIP file uploaded through the portal.
Secrets
Do not upload local .env files. Add needed values through Environment variables instead.
Deployment workflow
- 1Open Client portal, Serverless.
- 2Click New deployment.
- 3Name the site.
- 4Choose GitHub repo or Upload ZIP.
- 5Provide the source repository URL or ZIP file.
- 6Open Build and environment settings only when Vercel auto-detect is not enough.
- 7Add environment variables as KEY=value lines when needed.
- 8Click Deploy. The portal uploads the source to Vercel, starts a production deployment, and shows status and logs on the site detail page.
New user map
You have plain HTML/CSS/JS
Use ZIP upload or GitHub, choose Static / other if auto-detect needs help, and make sure index.html is present.
You have React with Vite
Use Vite preset, build command npm run build, output directory dist.
You have Next.js
Use Next.js preset, build command npm run build, and usually leave output directory blank.
You have a monorepo
Set Root directory to the folder that contains the app package.json.
You have secrets
Do not upload .env. Add each value under Environment variables.
You have a custom domain
Deploy first, then attach the domain and copy the DNS records shown by the portal.
Before you deploy
- Know whether your project is static HTML, Vite, Next.js, Astro, SvelteKit, Nuxt, Remix, Gatsby, Vue, Angular, or another framework.
- Confirm the app builds locally if you have a local development setup.
- Find the folder that contains package.json when the project uses Node tooling.
- Know the build command and output folder, or leave advanced fields blank for auto-detect.
- Collect required environment variables but do not paste secret values into public tickets or screenshots.
- Decide whether to deploy from GitHub for repeatability or ZIP for a one-time upload.