Documentation

Sasa Dev Hostings can deploy every supported project type. The platform detects the framework automatically by inspecting files such as package.json, next.config.js, next.config.mjs, vite.config.js, vite.config.ts, astro.config.mjs, nuxt.config.ts, svelte.config.js, project config files and index.html.

Supported: Next.js, React, Vite, HTML/CSS/JS static sites, Astro, Nuxt, Vue, SvelteKit, Remix, Gatsby, Hugo, Jekyll, Node.js serverless API projects and other supported frameworks.

Unsupported projects are rejected with a clear error before any deployment starts.

Detection order: project configuration first (custom configurations are respected), then next.config.*, astro.config.*, nuxt.config.*, svelte.config.js with @sveltejs/kit, gatsby.config*, remix.config*, vite.config.*, react-scripts, vue-cli, Hugo/Jekyll configs, and finally index.html for static sites.

Node.js serverless API projects are supported when they expose an api/ folder or a project configuration file.

You can always override the detected build command, output directory, install command and root directory in the deploy form.

1. Connect GitHub (OAuth) — or skip it entirely and upload your website files.

2. Import a repository from your GitHub account, paste a public repository URL, fork a public repository, or upload a ZIP archive / a set of files.

3. Select the branch and (optionally) adjust build settings and add environment variables.

4. The platform downloads (or receives) the files, detects the framework, prepares the build (including Free-plan watermark injection and source optimization) and publishes it to your subdomain.

5. Watch the live build log while it runs, then track everything in Deployment History. Every website gets its own unique subdomain.

Website names are checked across the whole platform — a name already in use cannot be registered.

Dashboard → New Deployment → Upload files. Drop a ZIP archive or pick files directly — the folder structure is preserved and a wrapping folder inside the ZIP is flattened automatically.

Uploads support the same options as GitHub deployments: website name (subdomain), environment variables, minification and source protection.

An index.html is required at the root, or in a folder such as public/ — a single differently named .html file (e.g. home.html) is also used as the home page.

Maximum 60 MB unpacked per website. Uploaded websites can be redeployed at any time — the published bundle is kept, so you never have to upload the files again.

On the Pro plan a website can be published as a Node.js app or as a Bot / worker instead of a static site. Choose the hosting type in the deploy form: Static website, Node.js app (gets a public URL and a PORT) or Bot / worker (runs 24/7 without a public URL).

The platform writes your project files, installs npm dependencies (npm ci when a lock file is present, otherwise npm install), runs npm run build when your package.json has a build script (development dependencies are installed in that case), then starts the process with your run command — or auto-detects it from the start script, the package.json main entry, or files such as index.js, server.js, app.js, main.js and bot.js.

Full-stack projects are supported: Express, NestJS, Fastify, TypeScript builds, server-rendered frameworks and API backends, as are monorepos where you set the root directory (for example backend) in the deploy form — install, build and start then run inside that folder.

Node.js apps are given a PORT environment variable and answer requests on your website address, including custom domains. Bots and workers run in the background and report their output to the Runtime tab.

Every runtime project has a Runtime tab with Start, Stop, Restart, log output, log clearing and its own settings. Processes are watched automatically: if one exits it is restarted with a backoff, and repeated crashes stop the project with a notification so a broken project never loops forever.

Limits: each runtime project may use up to 60 MB of project files, npm install has a 8 minute cap, and each platform instance runs a fixed number of runtime projects at the same time. Runtime projects run on the platform host, so long-running work belongs here rather than in a static deploy.

Your process can reach any API on the internet. Incoming WebSocket connections are not proxied to runtime projects; other HTTP traffic is proxied normally, and visitors get a clear starting page while an app boots.

Every deployment streams a build log: files received, framework detection, watermark and optimization steps, bundle packaging, storage upload and domain assignment.

Logs stay attached to each deployment — open Deployment History (or the Deployments tab of a website) and press “Build logs”.

A failed deployment shows the exact reason in the log and on the deployment record.

Website → Domains → Add domain. Enter your domain (e.g. www.mysite.com) and the platform registers it and returns a DNS target.

Create the record it shows you: a CNAME for subdomains, or an ALIAS / ANAME / CNAME-flattening record for an apex domain (mysite.com). If your domain is on Cloudflare, turn the orange cloud off while the certificate is issued.

Press Verify — once DNS resolves and the TLS certificate is issued, the website is served from your own domain over HTTPS. Your platform subdomain keeps working too.

You can add several domains per website and remove them at any time.

The Free plan allows a maximum of 3 hosted websites per user. This limit is enforced on the server — it cannot be bypassed from the browser.

Free deployments display a fixed bottom-right watermark: Built By Sasa Hostings. It links to the Sasa Dev Hostings homepage, cannot be disabled from dashboard settings, and is injected during build preparation (recorded in deployment metadata).

Projects without a safe watermark injection point must be deployed on Pro.

HTTPS, unique subdomains, environment variables and deployment history are included on Free.

Pro removes the watermark and unlocks unlimited website hosting within applicable fair-use limits.

Pro adds the browser-based file editor (Monaco), live editing with real GitHub commits, branch management, commit history, rollback controls, preview deployments, advanced logs, environment variable groups, project duplication and archive, configuration import/export, dependency vulnerability warnings and priority support.

Pro access is granted by the platform after an order is completed — plan status is always read server-side.

GitHub OAuth requests only the minimum scope (repo) needed to list/import private repositories and fork public ones. Tokens are encrypted with AES-256-GCM before being stored and are never returned to the browser.

Websites are hosted directly by the platform — no external hosting account is needed.

Sessions use HTTP-only, Secure, SameSite=Lax cookies backed by server-side Firebase ID-token verification. Deployment features require a verified email.

The admin panel is protected by a bcrypt-hashed password (ADMIN_PASSWORD_HASH), with rate limiting, failed-login tracking and session expiry.