Why GitHub-centric deployment feels like the default
Many popular deployment platforms are designed around a connected Git repository. You connect GitHub, choose a repository and branch, and each push can start a new build and deployment. That is an excellent workflow for a team already using Git for source control, pull requests, and continuous delivery. It can feel like a poor fit when a website was built locally, generated by an AI tool, delivered as a folder or ZIP, or simply is not ready to live in a GitHub repository.
- A Git-based workflow can add repository setup, access permissions, commits, and branch conventions before you can share a simple site.
- Platforms such as Vercel support convenient Git integrations, so their default experience often starts with connecting a repository.
- Using GitHub for source control can still be valuable, but it should not be a requirement for putting a working website online.
One traditional option: copy files to a VPS over SSH
You can rent a virtual private server (VPS), create an SSH key, and copy your site files to the server yourself. Google Cloud Compute Engine, Azure Virtual Machines, and Amazon EC2 on AWS are common places to run a VPS. For a static site, you might copy a built folder to a server with scp or synchronize it with rsync over SSH. For an application, you can copy source files and start the server process on the machine.
scp -r dist/* [email protected]:/var/www/my-site/rsync -avz --delete dist/ [email protected]:/var/www/my-site/What you take on when you manage the VPS
SSH file transfer gives you control, but the server is now your responsibility. You need to decide how the site is served, how the domain reaches the machine, and how the machine stays secure and available. This can be the right choice when your team already operates servers, but it is more setup than many prototypes and small sites need.
- Install and configure a web server such as NGINX, or keep an application process running with a process manager or container runtime.
- Configure firewall rules and DNS, then obtain and renew HTTPS certificates.
- Manage operating-system updates, SSH keys, backups, logs, deployments, and a rollback plan.
- Make sure each file copy is complete and that cached assets and server processes are refreshed safely.
Use Sitedropper when you want to skip the repository and server work
Sitedropper is built for taking the project you already have to a live URL. Instead of connecting a GitHub repository or administering a VPS, upload a ZIP from the dashboard, ask an MCP-connected coding agent to package and deploy the local project, or automate the same flow with the REST API. Sitedropper analyzes the archive, builds supported projects, deploys the result, and returns a URL while you keep control over visibility.
- Use ZIP upload when you have a folder or build output and want a browser-based deployment path.
- Use Sitedropper MCP when Codex, Claude Code, Cursor, or another coding agent should deploy the project from your local workspace.
- Use the REST API when a script or internal workflow should package, deploy, poll progress, and verify the result.
- Start with Draft, Private, or Password Protected visibility while you test, then choose Public only when the site is ready.
Choose the path that matches the job
Git-connected deployments are useful for teams with an established repository workflow, and a VPS is useful when you need to operate the server yourself. For a local project, prototype, client demo, or AI-built website that needs a link now, Sitedropper provides a direct Local-to-Live path without making GitHub or SSH server administration the first step.