Self-Host Bolt.new on a VPS with Bolt DIY

Updated 9 November 2026 · Standard formula, shown below

Self-hosting Bolt.new on a VPS lets you run its web development environment on a server you control and reach it through a browser. Bolt DIY is a community-maintained, self-hostable version of the Bolt interface; expect to configure the app and its AI provider yourself. You will need a Linux VPS, a domain or server address, and an API key for a supported model provider.

What You’ll Need

A VPS running a current 64-bit Linux distribution, with at least 2 CPU cores and 4 GB of RAM as a practical starting point. More resources may be needed for concurrent users or larger projects.
SSH access with a user account that can run commands using sudo.
A domain name with DNS access if you want HTTPS on a memorable address. A server IP can be used for initial testing.
Git and Docker Engine with the Docker Compose plugin, or the ability to install them. Check the repository’s current instructions for any additional requirements.
An API key and account with a model provider supported by the version of Bolt DIY you install. API usage may incur charges.

Step-by-Step

Choose a VPS and secure access. Create a Linux server, note its public IP, and connect from your computer with ssh username@SERVER_IP. Replace the placeholders with your actual values. Use a non-root account with sudo where possible, keep the operating system updated, and allow SSH only from trusted addresses if your provider offers that option.
Install Docker and Git. Follow the official installation instructions for your Linux distribution and Docker’s Compose plugin. Avoid copying an install command from an unrelated guide. Confirm installation with docker --version and docker compose version. If either command is unavailable, correct that before continuing.
Find the current Bolt DIY repository and instructions. Locate the project’s maintained source repository and read its README, deployment notes, and environment-variable example before running anything. Project names, repository locations, supported providers, and deployment files can change. Use the project’s documented clone URL rather than guessing it. Clone the repository, then enter its directory, for example with git clone REPOSITORY_URL followed by cd REPOSITORY_DIRECTORY.
Review the configuration template. Look for files such as .env.example, Compose YAML files, or documented setup prompts. Copy the example to the filename the project specifies, commonly .env. Set the provider and model values exactly as the current documentation describes. Do not assume variable names from another Bolt DIY release. Keep the API key private; do not paste it into source code, commit it to Git, or put it in a public issue.
Set a secure access plan. Decide whether the app will be reachable directly, behind a reverse proxy, or through a VPN. Do not expose an unfinished service openly just to see if it works. If the app supports authentication, configure it before public access. A firewall should expose only the ports you need; commonly that means SSH and, for a public HTTPS site, ports 80 and 443. Do not open a container’s internal development port to the whole internet by default.
Start the application using the project’s documented command. From the repository directory, follow its Compose instructions; a common pattern is docker compose up -d --build, but use it only if the project specifies it. Check startup with docker compose ps and review output using docker compose logs --tail=100. Resolve errors before proceeding rather than repeatedly restarting a failing stack.
Test locally on the VPS. Read the Compose configuration and logs to identify the published port and health check. From the server, test the documented local address with a command such as curl -I http://127.0.0.1:PORT, replacing PORT with the actual port. A successful response indicates the web service is answering locally; it does not prove DNS, firewall, or HTTPS is configured.
Connect a domain and enable HTTPS. If using a domain, create an A record pointing to the VPS IPv4 address, and an AAAA record only if IPv6 is configured and reachable. Allow DNS time to update. Configure a maintained reverse proxy and a trusted certificate using that proxy’s documented setup. Set the app’s public URL or origin variables if the project requires them, then restart the relevant services. Visit the HTTPS address and confirm the browser shows a valid certificate.
Check the full workflow and maintain it. Open the site, create a small test project, and verify that the selected model responds. Inspect logs if it does not. Back up any project data and configuration you need to retain, storing secrets securely and outside public source control. For updates, read release notes, back up first, then use the repository’s documented update process and verify the app afterward.

Common Mistakes

Following instructions for a different repository or release. Confirm that the README matches the code you cloned.
Using environment-variable names or model IDs copied from an old guide. Use the current project template and provider documentation.
Publishing the app’s raw development port to the internet without authentication or a proxy. Restrict access until the deployment is deliberately secured.
Putting an API key in a Docker image, committed file, or browser-visible configuration. Rotate it promptly if exposed.
Assuming the site is broken when the page loads but model requests fail. The app may be reachable while provider credentials, model selection, or outbound network access are wrong.

Tips

Keep a private record of the repository revision, configuration choices, and commands that successfully deployed your instance.
Use a separate API key for this deployment when possible, and set provider-side usage limits or alerts if available.
Check disk space and memory periodically. Container logs and saved projects can grow over time.
Keep the VPS, Docker, reverse proxy, and application dependencies updated, but back up important data before changes.

Troubleshooting

SSH times out: Confirm the IP address, VPS status, SSH username, and firewall rules. Make sure the server allows your client’s IP on the SSH port.
Compose reports a configuration error: Run commands from the correct project directory, check that the required environment file exists, and compare it with the current template. Do not post a full configuration publicly; redact secrets first.
The container exits or keeps restarting: Inspect docker compose logs for missing variables, invalid configuration, permission problems, or resource limits. Check available memory and disk with standard Linux tools before increasing VPS capacity.
The site will not load from your computer: Verify the container is running and the documented port is published. Then check the server firewall and VPS provider firewall. Do not open extra ports until you know which service needs them.
Domain or HTTPS fails: Check that DNS points to the correct address, ports 80 and 443 reach the proxy, and the certificate setup uses the same hostname you visit. An incorrect AAAA record can send some visitors to an unreachable IPv6 address.
Model requests fail: Check the provider key, selected model, provider account status, and outbound connectivity. Review server logs for useful errors, but remove keys and personal data before sharing them.

Frequently Asked Questions

Is Bolt DIY the same as the hosted Bolt.new service?
No. Bolt DIY is a self-hostable community project based on the Bolt-style coding experience. Its features, provider support, and setup can differ from the hosted service.

Do I need an API key?
Usually, yes, if you want the app to make requests to an external AI model. Confirm which providers and configuration fields your chosen release supports.

Can I deploy it without a domain?
You can test using the VPS IP and a permitted port, but HTTPS and safe public access are more straightforward with a domain and reverse proxy. Avoid exposing an unprotected instance.

Does the VPS need a GPU?
Not necessarily when the app calls a remote model provider. Running a model locally is a separate setup and may require substantially different hardware and configuration.

Will my projects survive an update?
That depends on where the deployment stores project data. Identify persistent volumes or storage paths in the Compose configuration and back them up before updating.

Can I use this for multiple people?
Possibly, but confirm the project’s access controls and resource requirements first. Do not treat an open URL as private access; configure authentication or restrict the service to a trusted network.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.