Deploy from Git_

Appwrite Sites allows you to host and deploy websites directly within the Appwrite platform. Each site can have many deployments, which can be thought of as versions of the web application.

With Appwrite Sites, you can seamlessly deploy updates from Git repositories, enabling you to track changes to your web app as part of your development workflow. This versioning approach ensures that your site stays up-to-date and your deployment process is fully integrated with your source control, streamlining collaboration and updates.

Create deployment

The recommended way to manage your Appwrite Sites deployments is to use a version control system like Git. This offers simple versioning and collaboration that will easily fit into the rest of your development workflow.

You can only use Git deployment for Appwrite Sites connected to Git. Create a new site with GitHub or connect your existing site to a GitHub repository in your site’s Settings > Git repository > Connect Git.

1. Using Git, checkout to the branch you configured as the production branch when creating the Appwrite Site.
2. Create a new commit.
3. Push the commit.
4. A new deployment will be automatically created, built, and activated.

Commits to the production branch

When you push a commit to the production branch, usually main, a new deployment is created, built, and activated. This means the new deployments immediately replace the current active deployment and can be used on your site’s primary domain.

Commits to other branches

When you push a commit to a branch other than the production branch, a new deployment is created, but it is not activated. A preview link is generated to test this deployment; however, only authorized users, i.e., members of your Appwrite organization, can access this link.

Git configuration

If you need to update your Git configuration, navigate to Sites > your site > Settings > Git repository.

Build triggers

Build triggers control which Git changes create automatic deployments. You can configure branch filters and path filters with glob patterns.

Branch filters match branch names. Add patterns to limit automatic deployments to specific branches.

main
staging
preview/**

Path filters match files changed in a commit or pull request. Leave this field empty to create deployments for all file changes, or add patterns to deploy only when specific files change.

apps/web/**
packages/ui/**
!docs/**

Use these formats to write glob patterns.

Install command

The install command of your site allow you to install your site’s dependencies. You can specify custom install scripts such as ones that let you configure your npm command with options or use an alternative package manager such as pnpm or yarn.

Build command

The build command of your site allow you to create a build of the site ready for output. You can specify custom build scripts, customize your npm command options, or use alternative package managers.

Output directory

The output directory will contain the files generated by your site's build command. The contents of this directory will be available to view on your site's public URL.

Monorepos

Appwrite Sites can deploy server-rendered apps from npm, pnpm, and Bun workspaces. Appwrite installs and builds the workspace from the root of the repository, then deploys your app's build output together with its dependencies and the workspace packages it imports. Code from the other apps in the repository isn't included in the deployment.

Monorepo deployments work with every JavaScript framework that Appwrite Sites renders on the server: Next.js, Nuxt, Astro, SvelteKit, Remix, TanStack Start, Angular, and Analog.

Here's an example pnpm workspace, with a Next.js app in apps/web that imports a shared package from packages/ui:

acme/
├── apps/
│   ├── web/          # the Next.js app to deploy
│   └── docs/
├── packages/
│   └── ui/
├── package.json
├── pnpm-lock.yaml
└── pnpm-workspace.yaml

These are the settings to use, either when creating the site or later in its settings:

• Root directory: ./, the root of the repository. The lockfile and the workspace config need to be inside the root directory.
• Framework: your app's framework, selected by hand. Automatic detection reads the package.json and config files in the root directory, and in a monorepo those belong to the workspace rather than your app.
• Install command: a command that installs the whole workspace, such as pnpm install.
• Build command: a command that builds only your app, such as pnpm --filter web build, where web is the name field in your app's package.json.
• Output directory: the path to your app's build output from the root of the repository, such as ./apps/web/.next.

The install and build commands for each package manager look like this:

Workspace packages that have their own build step need to be built in the same command.

To deploy several apps from one repository, create one site per app, each with its own build command and output directory. Path filters on each site keep it from deploying when only another app changes, for example apps/web/**, packages/**, and your lockfile. Listing the individual packages the app imports, instead of packages/**, narrows this further.

These setups aren't supported:

• Yarn Plug'n'Play.
• pnpm with shared-workspace-lockfile=false.
• Workspace packages that ship raw TypeScript and are loaded by Node.js at runtime. Node.js doesn't strip types from files in node_modules, so these packages need to be compiled in your build command or bundled by your framework, for example with transpilePackages in Next.js.

Debugging

• If you updated your site's configuration but the deployment is not working as expected, you may need to first redeploy your site before the changes take effect.
• If you're missing some code files at build time, verify your build command and ensure that the build output is included in the Git configuration's output directory. Only files in the output directory folder will be available after deployment.
• If you're self-hosting Appwrite, you will need to configure some environment variables to enable Git deployments.