# Create a site for Laravel, WordPress, Next.js and more

> Create a site on your server from a framework preset such as Laravel, WordPress or Next.js, with a repository, database, domain and free test address.

A **site** in Vimonto Deploy is one website or app on one of your servers: its own domain, Nginx configuration, code, `.env` and deploys. You create it from a framework preset (Laravel, WordPress, Next.js and others), which picks the runtime, the web directory, the build command and a deploy script that fits.

When you create a site, Vimonto Deploy sets it up on the server, links its repository and deploys it straight away. A few minutes later the site is live on a generated `on-deploy.link` address, even before you have touched DNS.

![The new-site form with a server, repository, database and generated address filled in](https://ops.vimonto.com/docs-media/en/create-site.webp?v=161e760d "Creating a Laravel site")

![Filling in the new-site form and creating the site](https://ops.vimonto.com/docs-media/en/create-site.mp4?v=161e760d)

## Find all your sites

The **Sites** tab in the top bar lists every site of the organization, across all its servers. Each row shows the domain with the framework's icon, and below it the server, the framework, the PHP version and the branch. **Deployed** says how long ago the site was last deployed (or **not deployed yet**), and **Status** shows whether it is ready or still busy. Search by domain, sort by a column, and click a row to open the site.

If your organization uses [teams](https://ops.vimonto.com/docs/organization/teams), you only see the sites on the servers you have access to. A server's own **Sites** page lists just the sites on that server.

![The organization's Sites list with each site's server, framework, last deploy and status](https://ops.vimonto.com/docs-media/en/sites-list.webp?v=161e760d "The organization's sites")

## Start a new site

1. Open a server and go to its **Sites** page.
2. Click **New site** and choose what the site is built with, for example **Laravel** or **WordPress**.
3. Fill in the form (each field is described below) and click **Create site**.

**New site** on the organization's **Sites** list has the same menu of frameworks. The form then lets you choose the server, and its **← Sites** link leads back to the organization's list instead of the server's.

Sites go on servers that serve websites: an app server or a web server. A load balancer only holds load-balanced sites (see [load balancing](https://ops.vimonto.com/docs/sites/load-balancing)). If there is no suitable server yet, the form says **No server for sites yet** and offers **New server**. See [server types](https://ops.vimonto.com/docs/servers/server-types) for what each type installs.

You need permission to manage sites in the organization; see [members and roles](https://ops.vimonto.com/docs/organization/members-and-roles). The free plan includes 3 sites across all servers of the organization; when they are used, the form shows **Your plan is full** with **See plans**. See [billing](https://ops.vimonto.com/docs/organization/billing).

## Which frameworks can you choose?

The **New site** menu groups the presets by language. Each preset sets the runtime (how Nginx serves the site) and sensible defaults, which you can change under **Advanced settings**.

| Preset | Runtime | Web directory | Composer | Default build command | Repository |
|---|---|---|---|---|---|
| Laravel | Laravel (PHP) | `/public` | Yes | `npm run build` | Yes |
| Symfony | PHP | `/public` | Yes | none | Yes |
| Statamic | Laravel (PHP) | `/public` | Yes | `npm run build` | Yes |
| WordPress | PHP | `/` | No | none | No, installed for you |
| phpMyAdmin | PHP | `/` | No | none | No, installed for you |
| PHP | PHP | `/public` | Yes | none | Yes |
| Next.js | Node.js | not used | No | `npm run build` | Yes |
| Nuxt | Node.js | not used | No | `npm run build` | Yes |
| HTML | Static | `/` | No | none | Yes |
| Other | PHP | `/` | No | none | Yes |
| Load balancer | Proxy to your app servers | not used | No | none | No |

What the runtimes mean:

- **Laravel**: PHP-FPM behind Nginx, with Laravel's `storage/` shared between releases, queue workers and the scheduler.
- **PHP**: any PHP app with an `index.php`, such as Symfony or WordPress.
- **Static**: HTML, or a frontend that is built into files (Vite, Astro, a static Next.js export).
- **Node.js**: an app that listens on a port; Nginx passes requests to it.

The **Load balancer** preset, under **Load balancing** in the menu, is only for load balancer servers and is the only kind of site they hold. It has no code and no deploys: it passes requests on to your app servers. Its form has no repository, database or **Advanced settings**, since there is nothing to build or isolate. See [load balancing](https://ops.vimonto.com/docs/sites/load-balancing).

### WordPress and phpMyAdmin

WordPress and phpMyAdmin need no repository. Vimonto Deploy downloads the latest release onto the server and writes its configuration:

- **WordPress** gets a `wp-config.php` with the database name, user and password, and fresh security keys and salts. WordPress always needs a database, so **Connect a database** cannot be switched off.
- **phpMyAdmin** gets a `config.inc.php` that logs in with cookie authentication to the database server on the same machine.

Open the site afterwards to finish the WordPress installation in the browser.

## Fill in the form

### Server

Choose the server the site goes on. Only active servers that can host this kind of site are listed, shown with their IP address: app and web servers for every preset, load balancers for the **Load balancer** preset only.

### Source code, repository and branch

Under **Source code**, choose one of your [Git connections](https://ops.vimonto.com/docs/connections/source-control) (GitHub, GitLab or Bitbucket), or **Custom Git URL**.

- With a connection, pick the **Repository** (optionally filtered by **Organization**) and the **Branch**.
- With **Custom Git URL**, type the **Git URL**, such as `git@github.com:you/project.git` or `https://github.com/you/project.git`, and the **Branch**.

The repository is optional. Without one, the site is set up with a placeholder page and you can connect a repository later on the [Deployments](https://ops.vimonto.com/docs/sites/deployments) page.

### Connect a database

On a server with a database, **Connect a database** is on by default with a new database named after the site (for example `shop_example_com`). You can:

- Click **Change** or **Create database** to choose the name, a **User** of its own and a **Password**. Leave the user empty to use the server's own database user. Leave the password empty and one is generated.
- Pick an existing database from the list. The site then gets a database user of its own for it, so it never shares a password with another site.

For Laravel and Statamic sites, the database name, user and password are written into the site's `.env`. See [databases](https://ops.vimonto.com/docs/servers/databases) for managing them later.

### Domain or generated address

Every site can get a free address on `on-deploy.link`, such as `kalme-rivier-4821.on-deploy.link`. You can change the first part of the name in the **on-deploy.link address** field. It works right away, without any DNS of your own, which makes it handy for testing and sharing. A site that runs on this address also gets HTTPS by itself (see below).

To use your own domain, click **Use a custom domain** and type it, for example `shop.example.com`. Keep **Also …on-deploy.link** checked if the site should answer on the generated address too.

Then the domain needs DNS records that point to the server. With DNS integrations, the hint under the domain says "We look the domain up at your DNS providers and set its records automatically." While you type, a **DNS** box shows whether one of your [integrations](https://ops.vimonto.com/docs/connections/integrations) (Hetzner Cloud, DigitalOcean, Vultr, Akamai, AWS, Google Cloud or Cloudflare) manages it; their domain lists are fetched live:

- If one does, **Point it automatically with …** is chosen. The box lists the records (an A record for the domain and a CNAME for `www.`) as **New**, **Already right** or **Changes**, with a warning for anything that changes or is removed. If existing records change, tick **Change these records**. After setup, Vimonto Deploy updates the records, waits until the domain resolves and requests HTTPS by itself. Choose **I manage the DNS myself** to leave the DNS alone.
- If none does but you have DNS integrations, switch on **Add the domain to a DNS provider** and choose the **Provider** and the **Zone** (by default the domain without its subdomain, such as `example.com`). Vimonto Deploy creates the zone there, sets the records and lists the nameservers to set at your registrar in the task output; HTTPS follows once the DNS resolves.
- Otherwise, point the domain to the server's IP address with an A record at your DNS provider yourself.

> [!TIP]
> Your domain's DNS can be set for you. Connect Cloudflare, Hetzner Cloud, DigitalOcean, Vultr, Akamai, AWS or Google Cloud under [integrations](https://ops.vimonto.com/docs/connections/integrations), and Vimonto Deploy finds the domain there, creates its records and requests HTTPS by itself. Without one, the domain form shows **Tip: let us set the DNS records** with a link to connect one.

See [domains and SSL](https://ops.vimonto.com/docs/sites/domains-and-ssl#point-your-domain-automatically-with-a-dns-integration) for what each warning means.

You can add more domains, switch the generated address off and turn on HTTPS later; see [domains and SSL](https://ops.vimonto.com/docs/sites/domains-and-ssl).

### Install Composer packages

For Laravel, Symfony, Statamic and PHP sites with a repository, **Install Composer packages** adds `composer install` to the deploy script. Turn it off if your project has no `composer.json` or installs its packages another way.

### Own deploy key

With **Own deploy key for GitHub** (or GitLab, Bitbucket; **Own deploy key for your Git host** with a custom Git URL) on, the default, the site gets an SSH key of its own for its repository. With a connected Git host, Vimonto Deploy registers it as a read-only deploy key on the repository. With a custom Git URL, you copy the key from the Deployments page and add it to your Git host yourself.

A repository from a connected Git host also gets **Deploy on every push** switched on: Vimonto Deploy adds a webhook, and every push to the branch deploys. You can switch it off on the [Deployments](https://ops.vimonto.com/docs/sites/deployments#push-to-deploy) page.

## Advanced settings

Click **Advanced settings** to change the defaults of the preset. Click **Save settings** to keep them.

| Setting | What it does |
|---|---|
| **Root directory** | Where the app lives in the repository. `/` is the whole repository; use `/backend` or similar for a monorepo. |
| **Web directory** | What Nginx serves, inside the root directory, such as `/public` or `/dist`. Not shown for Node.js sites. |
| **PHP version** | One of the PHP versions installed on the server. See [PHP](https://ops.vimonto.com/docs/servers/php). |
| **Frontend package manager** | npm (default), yarn, pnpm or bun. Yarn and pnpm run through Corepack. |
| **Build command** | Runs after the packages are installed, such as `npm run build`. Empty: build nothing. |
| **Website isolation** | Gives the site its own Linux user, with a **Username** you choose. |
| **Zero-downtime deploys** | Builds each deploy in a new release and only switches once it succeeded. On by default. |
| **Composer authentication** | Host, username and password or token for private Composer packages, such as `repo.packagist.com`. |
| **npm authentication** | Registry and token for a private npm registry, such as `https://npm.pkg.github.com`. |

### Deploy a monorepo

Set the **Root directory** to the folder of the app, for example `/backend`. The whole repository is cloned, but the deploy script runs in that folder, the `.env` is linked there, and the web directory is looked up inside it. A deploy fails with a clear message if the folder is not in the repository.

### Website isolation

An isolated site runs as its own Linux user, with a home directory other sites cannot read. A PHP site also gets its own PHP-FPM pool running as that user. Nginx can still serve the files because the server's system user joins the site's group. Use it when several clients or projects share one server.

The user is chosen when the site is created. The name must be lowercase letters, numbers, `_` and `-`, start with a letter, and not be a system name such as `root` or `www-data`.

### Zero-downtime deploys

With zero-downtime deploys, each deploy is built in a new release directory and goes live in one atomic switch, so visitors never see a half-built site and you can roll back. With it off, one release is updated in place: faster, but visitors may see the build happen and there is no rollback. You can change this later under [site settings](https://ops.vimonto.com/docs/sites/site-settings). See [deployments](https://ops.vimonto.com/docs/sites/deployments) for details.

### Private Composer and npm packages

The credentials under **Composer authentication** and **npm authentication** are stored encrypted and only used during the build: Composer reads them from `COMPOSER_AUTH`, and npm from a temporary config file that is removed afterwards. You can add, change or remove them later on the site's **Settings**, on the **Composer** and **npm** tabs: see [Composer and npm credentials](https://ops.vimonto.com/docs/sites/site-settings#composer-and-npm-credentials).

## What happens after you click Create site?

You land on the site's page, which shows only the setup until the site is live: the phases, the step that is running and the log of each task. You can leave the page at any time; the work goes on in the background.

1. **Set up**: Vimonto Deploy creates the DNS record for the generated address, creates the database and its user, makes the site's directories, writes the `.env`, the PHP-FPM pool (when isolated) and the Nginx configuration. Until the first deploy, the site shows a page saying it is ready. WordPress and phpMyAdmin are installed in this phase.
2. **Link**: with a repository, the deploy key is put on the server and, with a connected Git host, registered on the repository together with the push webhook.
3. **Fetch, Build, Live**: the first deploy clones the branch, runs the deploy script and makes the release live.
4. **HTTPS**: for a site whose address is the generated `on-deploy.link` address, and for a site on its own domain that a DNS integration points. For its own domain, Vimonto Deploy first updates the DNS records as the plan showed. Then it waits until the name points to the server (at most 10 minutes), requests a free Let's Encrypt certificate and switches the site to HTTPS. It runs alongside the first deploy and is the last phase shown. If it fails, the site keeps working over HTTP; request a certificate later under [domains and SSL](https://ops.vimonto.com/docs/sites/domains-and-ssl).

A site created with a domain of its own whose DNS you manage yourself skips the HTTPS phase, because its DNS may not point to the server yet. Request its certificate once it does.

While the setup runs (setting up, linking the repository, the first deploy and the first HTTPS certificate), this overview with its setup steps is the site's only page, together with the log of the first deploy: there is no sidebar, and the site's other pages lead back to it.

Once everything is done, the page becomes the site's normal overview with its sidebar. The first time you (or anyone else in the organization) open it after that, it starts with **Your site is live**, how long the setup took and an **Open** button; **Close** hides it, and later visits show the overview only.

On disk, every site lives in `/home/{user}/{domain}`, with `releases/`, `shared/` and a `current` symlink. The directory keeps its name when you change the site's domain later.

If a phase fails, the page says **Setup failed**, **Connecting the repository failed** or **First deploy failed**, with the error and the log of the step that went wrong (under **Details and log**). Fix the cause (a branch name, a missing deploy key) and use the button on the page: **Try again**, **Connect again** or **Deploy again**. When a phase failed, the sidebar and all the site's pages are back, so you can fix the cause on the **Deployments** and **Environment** pages.

### What to do next

- For a site on a domain of its own whose DNS you manage yourself, turn on HTTPS with a free Let's Encrypt certificate under [domains and SSL](https://ops.vimonto.com/docs/sites/domains-and-ssl).
- Check the `.env` under [environment](https://ops.vimonto.com/docs/sites/environment).
- For Laravel, add queue workers and the scheduler under [queues and scheduler](https://ops.vimonto.com/docs/sites/queues-and-scheduler), or switch on Horizon in the [site features](https://ops.vimonto.com/docs/sites/site-features) menu.
- With a custom Git URL, call the [deploy URL](https://ops.vimonto.com/docs/sites/deployments#deploy-from-ci-with-the-deploy-url) from your Git host or CI to deploy on a push.

![The sites of a server with their domains and last deploys](https://ops.vimonto.com/docs-media/en/server-sites.webp?v=161e760d "A server's sites")

## Frequently asked questions

### Do I need a domain to create a site?

No. Every site can get a generated `on-deploy.link` address that works right away. Add your own domain when you are ready.

### Can I host several sites on one server?

Yes. A server can hold as many sites as it has room for. Each site has its own Nginx configuration and directory; turn on website isolation to also give each its own Linux user.

### Which repository does WordPress use?

None. WordPress and phpMyAdmin are downloaded and installed on the server when the site is created. If you keep a WordPress project in Git, choose the **PHP** preset instead and connect your repository.

### How do I deploy a Next.js or Nuxt app?

Choose **Next.js** or **Nuxt**. The site gets a free local port (from 3000 upwards) that Nginx forwards to, and the deploy script installs packages and runs `npm run build`. Vimonto Deploy also adds the process that runs your app on that port, and the first deploy starts it. You find it under [Processes](https://ops.vimonto.com/docs/sites/queues-and-scheduler#run-a-nodejs-app).

### Can I spread a site over several servers?

Yes, with a load balancer server in front of two or more app servers that each run the same site. See [load balancing](https://ops.vimonto.com/docs/sites/load-balancing).

### Can I change the framework later?

No, the preset is chosen when the site is created. The PHP version, web directory, Node.js port and zero-downtime deploys can be changed under [site settings](https://ops.vimonto.com/docs/sites/site-settings), and the deploy script on the [Deployments](https://ops.vimonto.com/docs/sites/deployments) page.

### Can I copy an existing site?

Yes. On the site's **Settings**, click **Clone site** to make a new site with the same repository, build settings, deploy script and rules, on the same or another server. See [clone a site](https://ops.vimonto.com/docs/sites/site-settings#clone-a-site).