@vendure/docs 0.0.0-202601161541

package/docs/guides/core-concepts/stock-control/index.md

@@ -0,0 +1,233 @@
+---
+title: "Stock Control"
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+Vendure includes features to help manage your stock levels, stock allocations and back orders. The basic purpose is to help you keep track of how many of a given ProductVariant you have available to sell.
+
+Stock control is enabled globally via the Global Settings:
+
+![./global-stock-control.webp](./global-stock-control.webp)
+
+It can be disabled if, for example, you manage your stock with a separate inventory management system and synchronize stock levels into Vendure automatically. The setting can also be overridden at the individual ProductVariant level.
+
+## Stock Locations
+
+Vendure uses the concept of [`StockLocations`](/reference/typescript-api/entities/stock-location/) to represent the physical locations where stock is stored. This could be a warehouse, a retail store, or any other location. If you do not have multiple stock locations, then you can simply use the default location which is created automatically.
+
+![Stock levels](./stock-levels.webp)
+
+### Selecting a stock location
+
+When you have multiple stock locations set up, you need a way to determine which location to use when querying stock levels and when allocating stock to orders. This is handled by the [`StockLocationStrategy`](/reference/typescript-api/products-stock/stock-location-strategy/). This strategy exposes a number of methods which are used to determine which location (or locations) to use when:
+
+- querying stock levels (`getAvailableStock`)
+- allocating stock to orders (`forAllocation`)
+- releasing stock from orders (`forRelease`)
+- creating sales upon fulfillment (`forSale`)
+- returning items to stock upon cancellation (`forCancellation`)
+
+The default strategy is the [`DefaultStockLocationStrategy`](/reference/typescript-api/products-stock/default-stock-location-strategy), which simply uses the default location for all of the above methods. This is suitable for all cases where there is just a single stock location.
+
+If you have multiple stock locations, you'll need to implement a custom strategy which uses custom logic to determine which stock location to use. For instance, you could:
+
+- Use the location with the most stock available
+- Use the location closest to the customer
+- Use the location which has the cheapest shipping cost
+
+### Displaying stock levels in the storefront
+
+The [`StockDisplayStrategy`](/reference/typescript-api/products-stock/stock-display-strategy/) is used to determine how stock levels are displayed in the storefront. The default strategy is the [`DefaultStockDisplayStrategy`](/reference/typescript-api/products-stock/default-stock-display-strategy), which will only display one of three states: `'IN_STOCK'`, `'OUT_OF_STOCK'` or `'LOW_STOCK'`. This is to avoid exposing your exact stock levels to the public, which can sometimes be undesirable.
+
+You can implement a custom strategy to display stock levels in a different way. Here's how you would implement a custom strategy to display exact stock levels:
+
+```ts title="src/exact-stock-display-strategy.ts"
+import { RequestContext, StockDisplayStrategy, ProductVariant } from '@vendure/core';
+
+export class ExactStockDisplayStrategy implements StockDisplayStrategy {
+    getStockLevel(ctx: RequestContext, productVariant: ProductVariant, saleableStockLevel: number): string {
+        return saleableStockLevel.toString();
+    }
+}
+```
+
+This strategy is then used in your config:
+
+```ts title="src/vendure-config.ts"
+import { VendureConfig } from '@vendure/core';
+import { ExactStockDisplayStrategy } from './exact-stock-display-strategy';
+
+export const config: VendureConfig = {
+    // ...
+    catalogOptions: {
+        stockDisplayStrategy: new ExactStockDisplayStrategy(),
+    },
+};
+```
+
+## Stock Control Concepts
+
+* **Stock on hand:** This refers to the number of physical units of a particular variant which you have in stock right now. This can be zero or more, but not negative.
+* **Allocated:** This refers to the number of units which have been assigned to Orders, but which have not yet been fulfilled.
+* **Out-of-stock threshold:** This value determines the stock level at which the variant is considered "out of stock". This value is set globally, but can be overridden for specific variants. It defaults to `0`.
+* **Saleable:** This means the number of units that can be sold right now. The formula is:
+    `saleable = stockOnHand - allocated - outOfStockThreshold`
+
+Here's a table to better illustrate the relationship between these concepts:
+
+Stock on hand | Allocated | Out-of-stock threshold | Saleable
+--------------|-----------|------------------------|----------
+10            | 0         | 0                      | 10
+10            | 0         | 3                      | 7
+10            | 5         | 0                      | 5
+10            | 5         | 3                      | 2
+10            | 10        | 0                      | 0
+10            | 10        | -5                     | 5
+
+The saleable value is what determines whether the customer is able to add a variant to an order. If there is 0 saleable stock, then any attempt to add to the order will result in an [`InsufficientStockError`](/reference/graphql-api/admin/object-types/#insufficientstockerror).
+
+
+<Tabs>
+<TabItem value="Request" label="Request" default>
+
+```graphql title="Shop API"
+query AddItemToOrder {
+    addItemToOrder(productVariantId: 123, quantity: 150) {
+        ...on Order {
+            id
+            code
+            totalQuantity
+        }
+        ...on ErrorResult {
+            errorCode
+            message
+        }
+        ...on InsufficientStockError {
+            errorCode
+            message
+            quantityAvailable
+            order {
+                id
+                totalQuantity
+            }
+        }
+    }
+}
+```
+
+</TabItem>
+<TabItem value="Response" label="Response">
+
+```json
+{
+  "data": {
+    "addItemToOrder": {
+      "errorCode": "INSUFFICIENT_STOCK_ERROR",
+      "message": "Only 105 items were added to the order due to insufficient stock",
+      "quantityAvailable": 105,
+      "order": {
+        "id": "2",
+        "totalQuantity": 106
+      }
+    }
+  }
+}
+```
+
+</TabItem>
+</Tabs>
+
+### Stock allocation
+
+Allocation mean we are setting stock aside because it has been purchased but not yet shipped. It prevents us from selling more of a particular item than we are able to deliver. 
+
+By default, stock gets allocated to an order once the order transitions to the `PaymentAuthorized` or `PaymentSettled` state. This is defined by the [`DefaultStockAllocationStrategy`](/reference/typescript-api/orders/default-stock-allocation-strategy). Using a custom [`StockAllocationStrategy`](/reference/typescript-api/orders/stock-allocation-strategy/) you can define your own rules for when stock is allocated.
+
+With the [`defaultFulfillmentProcess`](/reference/typescript-api/fulfillment/fulfillment-process/#defaultfulfillmentprocess), allocated stock will be converted to **sales** and minused from the `stockOnHand` value when a Fulfillment is created.
+
+
+### Back orders
+
+You may have noticed that the `outOfStockThreshold` value can be set to a negative number. This allows you to sell variants even when you don't physically have them in stock. This is known as a "back order". 
+
+Back orders can be really useful to allow orders to keep flowing even when stockOnHand temporarily drops to zero. For many businesses with predictable re-supply schedules they make a lot of sense.
+
+Once a customer completes checkout, those variants in the order are marked as `allocated`. When a Fulfillment is created, those allocations are converted to Sales and the `stockOnHand` of each variant is adjusted. Fulfillments may only be created if there is sufficient stock on hand.
+
+### Stock movements
+
+There is a [`StockMovement`](/reference/typescript-api/entities/stock-movement/) entity which records the history of stock changes. `StockMovement` is actually an abstract class, with the following concrete implementations:
+
+- [`Allocation`](/reference/typescript-api/entities/stock-movement/#allocation): When stock is allocated to an order, before the order is fulfilled. Adds stock to `allocated`, which reduces the saleable stock.
+- [`Sale`](/reference/typescript-api/entities/stock-movement/#sale): When allocated stock gets fulfilled. Removes stock from `allocated` as well as `stockOnHand`.
+- [`Cancellation`](/reference/typescript-api/entities/stock-movement/#cancellation): When items from a fulfilled order are cancelled, the stock is returned to `stockOnHand`. Adds stock to `stockOnHand`.
+- [`Release`](/reference/typescript-api/entities/stock-movement/#release): When items which have been allocated (but not yet converted to sales via the creation of a Fulfillment) are cancelled. Removes stock from `allocated`.
+- [`StockAdjustment`](/reference/typescript-api/entities/stock-movement/#stockadjustment): A general-purpose stock adjustment. Adds or removes stock from `stockOnHand`. Used when manually setting stock levels via the Dashboard, for example.
+
+Stock movements can be queried via the `ProductVariant.stockMovements`. Here's an example where we query the stock levels and stock movements of a particular variant:
+
+
+<Tabs>
+<TabItem value="Request" label="Request" default>
+
+```graphql title="Admin API"
+query GetStockMovements {
+    productVariant(id: 1) {
+        id
+        name
+        stockLevels {
+            stockLocation {
+                name
+            }
+            stockOnHand
+            stockAllocated
+        }
+        stockMovements {
+            items {
+                ...on StockMovement {
+                    createdAt
+                    type
+                    quantity
+                }
+            }
+        }
+    }
+}
+```
+
+</TabItem>
+<TabItem value="Response" label="Response">
+
+```json
+{
+  "data": {
+    "productVariant": {
+      "id": "1",
+      "name": "Laptop 13 inch 8GB",
+      "stockLevels": [
+        {
+          "stockLocation": {
+            "name": "Default Stock Location"
+          },
+          "stockOnHand": 100,
+          "stockAllocated": 0
+        }
+      ],
+      "stockMovements": {
+        "items": [
+          {
+            "createdAt": "2023-07-13T13:21:10.000Z",
+            "type": "ADJUSTMENT",
+            "quantity": 100
+          }
+        ]
+      }
+    }
+  }
+}
+```
+
+</TabItem>
+</Tabs>

package/docs/guides/core-concepts/taxes/index.mdx

@@ -0,0 +1,76 @@
+---
+title: "Taxes"
+showtoc: true
+---
+
+E-commerce applications need to correctly handle taxes such as sales tax or value added tax (VAT). In Vendure, tax handling consists of:
+
+* **Tax categories** Each ProductVariant is assigned to a specific TaxCategory. In some tax systems, the tax rate differs depending on the type of good. For example, VAT in the UK has 3 rates, "standard" (most goods), "reduced" (e.g. child car seats) and "zero" (e.g. books).
+* **Tax rates** This is the tax rate applied to a specific tax category for a specific [Zone](/reference/typescript-api/entities/zone/). E.g., the tax rate for "standard" goods in the UK Zone is 20%.
+* **Channel tax settings** Each Channel can specify whether the prices of product variants are inclusive of tax or not, and also specify the default Zone to use for tax calculations.
+* **TaxZoneStrategy** Determines the active tax Zone used when calculating what TaxRate to apply. By default, it uses the default tax Zone from the Channel settings.
+* **TaxLineCalculationStrategy** This determines the taxes applied when adding an item to an Order. If you want to integrate a 3rd-party tax API or other async lookup, this is where it would be done.
+
+## API conventions
+
+In the GraphQL API, any type which has a taxable price will split that price into two fields: `price` and `priceWithTax`. This pattern also holds for other price fields, e.g.
+
+```graphql
+query {
+  activeOrder {
+    ...on Order {
+      lines {
+        linePrice
+        linePriceWithTax
+      }
+      subTotal
+      subTotalWithTax
+      shipping
+      shippingWithTax
+      total
+      totalWithTax
+    }
+  }
+}
+```
+
+In your storefront, you can therefore choose whether to display the prices with or without tax, according to the laws and conventions of the area in which your business operates.
+
+## Calculating tax on order lines
+
+When a customer adds an item to the Order, the following logic takes place:
+
+1. The price of the item, and whether that price is inclusive of tax, is determined according to the configured [OrderItemPriceCalculationStrategy](/reference/typescript-api/orders/order-item-price-calculation-strategy/).
+2. The active tax Zone is determined based on the configured [TaxZoneStrategy](/reference/typescript-api/tax/tax-zone-strategy/). By default, Vendure will use the default tax Zone from the Channel settings.
+  However, you often want to use the customer's address as the basis for determining the tax Zone. In this case, you should use the [AddressBasedTaxZoneStrategy](/reference/typescript-api/tax/address-based-tax-zone-strategy).
+3. The applicable TaxRate is fetched based on the ProductVariant's TaxCategory and the active tax Zone determined in step 1.
+4. The `TaxLineCalculationStrategy.calculate()` of the configured [TaxLineCalculationStrategy](/reference/typescript-api/tax/tax-line-calculation-strategy/) is called, which will return one or more [TaxLines](/reference/graphql-api/admin/object-types/#taxline).
+5. The final `priceWithTax` of the order line is calculated based on all the above.
+
+## Calculating tax on shipping
+
+The taxes on shipping is calculated by the [ShippingCalculator](/reference/typescript-api/shipping/shipping-calculator/) of the Order's selected [ShippingMethod](/reference/typescript-api/entities/shipping-method/).
+
+## Configuration
+
+This example shows the default configuration for taxes (you don't need to specify this in your own config, as these are the defaults):
+
+```ts title="src/vendure-config.ts"
+import {
+    DefaultTaxLineCalculationStrategy,
+    DefaultTaxZoneStrategy,
+    DefaultOrderItemPriceCalculationStrategy,
+    VendureConfig
+} from '@vendure/core';
+
+export const config: VendureConfig = {
+  taxOptions: {
+    taxZoneStrategy: new DefaultTaxZoneStrategy(),
+    taxLineCalculationStrategy: new DefaultTaxLineCalculationStrategy(),
+  },
+  orderOptions: {
+    orderItemPriceCalculationStrategy: new DefaultOrderItemPriceCalculationStrategy()
+  }
+}
+
+```

package/docs/guides/deployment/deploy-to-digital-ocean-app-platform/index.md

@@ -0,0 +1,246 @@
+---
+title: "Deploying to Digital Ocean"
+---
+
+![Deploy to Digital Ocean App Platform](./deploy-to-do-app-platform.webp)
+
+[App Platform](https://www.digitalocean.com/products/app-platform) is a fully managed platform which allows you to deploy and scale your Vendure server and infrastructure with ease.
+
+:::note
+The configuration in this guide will cost around $22 per month to run.
+:::
+
+## Prerequisites
+
+First of all you'll need to [create a new Digital Ocean account](https://cloud.digitalocean.com/registrations/new) if you
+don't already have one.
+
+For this guide you'll need to have your Vendure project in a git repo on either GitHub or GitLab. App Platform also supports
+deploying from docker registries, but that is out of the scope of this guide.
+
+:::info
+If you'd like to quickly get started with a ready-made Vendure project which includes sample data, you can clone our
+[Vendure one-click-deploy repo](https://github.com/vendurehq/one-click-deploy).
+:::
+
+## Configuration
+
+### Database connection
+
+:::info
+The following is already pre-configured if you are using the one-click-deploy repo.
+:::
+
+Make sure your DB connection options uses the following environment variables:
+
+```ts title="src/vendure-config.ts"
+import { VendureConfig } from '@vendure/core';
+
+export const config: VendureConfig = {
+    // ...
+    dbConnectionOptions: {
+        // ...
+        type: 'postgres',
+        database: process.env.DB_NAME,
+        host: process.env.DB_HOST,
+        port: +process.env.DB_PORT,
+        username: process.env.DB_USERNAME,
+        password: process.env.DB_PASSWORD,
+        ssl: process.env.DB_CA_CERT ? {
+            ca: process.env.DB_CA_CERT,
+        } : undefined,
+    },
+};
+```
+### Asset storage
+
+:::info
+The following is already pre-configured if you are using the one-click-deploy repo.
+:::
+
+Since App Platform services do not include any persistent storage, we need to configure Vendure to use Digital Ocean's
+Spaces service, which is an S3-compatible object storage service. This means you'll need to make sure to have the
+following packages installed:
+
+```
+npm install @aws-sdk/client-s3 @aws-sdk/lib-storage
+```
+
+
+and set up your AssetServerPlugin like this:
+
+```ts title="src/vendure-config.ts"
+import { VendureConfig } from '@vendure/core';
+import { AssetServerPlugin, configureS3AssetStorage } from '@vendure/asset-server-plugin';
+
+export const config: VendureConfig = {
+    // ...
+    plugins: [
+        AssetServerPlugin.init({
+            route: 'assets',
+            assetUploadDir: process.env.ASSET_UPLOAD_DIR || path.join(__dirname, '../static/assets'),
+            // highlight-start
+            // If the MINIO_ENDPOINT environment variable is set, we'll use
+            // Minio as the asset storage provider. Otherwise, we'll use the
+            // default local provider.
+            storageStrategyFactory: process.env.MINIO_ENDPOINT ?  configureS3AssetStorage({
+                bucket: 'vendure-assets',
+                credentials: {
+                    accessKeyId: process.env.MINIO_ACCESS_KEY,
+                    secretAccessKey: process.env.MINIO_SECRET_KEY,
+                },
+                nativeS3Configuration: {
+                    endpoint: process.env.MINIO_ENDPOINT,
+                    forcePathStyle: true,
+                    signatureVersion: 'v4',
+                    // The `region` is required by the AWS SDK even when using MinIO,
+                    // so we just use a dummy value here.
+                    region: 'eu-west-1',
+                },
+            }) : undefined,
+            // highlight-end
+        }),
+    ],
+    // ...
+};
+```
+
+## Create Spaces Object Storage
+
+First we'll create a Spaces bucket to store our assets. Click the "Spaces Object Storage" nav item and
+create a new space and call it "vendure-assets".
+
+![Create Spaces Object Storage](./01-create-space.webp)
+
+Next we need to create an access key and secret. Click the "API" nav item and generate a new key.
+
+![Create API key](./02-space-access-keys.webp)
+
+Name the key something meaningful like "vendure-assets-key" and then **make sure to copy the secret as it will only be
+shown once**. Store the access key and secret key in a safe place for later - we'll be using it when we set up our 
+app's environment variables.
+
+:::caution
+If you forget to copy the secret key, you'll need to delete the key and create a new one.
+:::
+
+## Create the server resource
+
+Now we're ready to create our app infrastructure! Click the "Create" button in the top bar and select "Apps".
+
+![Create App](./03-create-app.webp)
+
+Now connect to your git repo, and select the repo of your Vendure project.
+
+Depending on your repo, App Platform may suggest more than one app: in this screenshot we are using the one-click-deploy
+repo which contains a Dockerfile, so App Platform is suggesting two different ways to deploy the app. We'll select the
+Dockerfile option, but either option should work fine. Delete the unused resource.
+
+We need to edit the details of the server app. Click the "Edit" button and set the following:
+
+* **Resource Name**: "vendure-server"
+* **Resource Type**: Web Service
+* **Run Command**: `node ./dist/index.js`
+* **HTTP Port**: 3000
+
+At this point you can also click the "Edit Plan" button to select the resource allocation for the server, which will
+determine performance and price. For testing purposes the smallest Basic server (512MB, 1vCPU) is fine. This can also be changed later.
+
+### Add a database 
+
+Next click "Add Resource", select **Database** and click "Add", and then accept the default Postgres database. Click the
+"Create and Attach" to create the database and attach it to the server app.
+
+Your config should now look like this:
+
+![App setup](./04-configure-server.webp)
+
+## Set up environment variables
+
+Next we need to set up the environment variables. Since these will be shared by both the server and worker apps, we'll create
+them at the Global level. 
+
+You can use the "bulk editor" to paste in the following variables (making sure to replace the values in `<angle brackets>` with
+your own values):
+
+```sh
+DB_NAME=${db.DATABASE}
+DB_USERNAME=${db.USERNAME}
+DB_PASSWORD=${db.PASSWORD}
+DB_HOST=${db.HOSTNAME}
+DB_PORT=${db.PORT}
+DB_CA_CERT=${db.CA_CERT}
+// highlight-next-line
+COOKIE_SECRET=<add some random characters>
+SUPERADMIN_USERNAME=superadmin
+// highlight-next-line
+SUPERADMIN_PASSWORD=<create some strong password>
+// highlight-start
+MINIO_ACCESS_KEY=<use the key generated earlier>
+MINIO_SECRET_KEY=<use the secret generated earlier>
+MINIO_ENDPOINT=<use the endpoint of your spaces bucket>
+// highlight-end
+```
+
+:::note
+The values starting with `${db...}` are automatically populated by App Platform and should not be changed, unless you chose
+to name your database something other than `db`.
+:::
+
+:::note
+When using the App Platform with a Dev Database, DigitalOcean only provides a self-signed SSL certificate. This may prevent the Vendure app from starting. As a workaround, you can add the environment variable `NODE_TLS_REJECT_UNAUTHORIZED` and set it to `0`.
+:::
+
+After saving your environment variables you can click through the confirmation screens to create the app.
+
+## Create the worker resource
+
+Now we need to set up the [Vendure worker](/guides/developer-guide/worker-job-queue/) which will handle background tasks. From the dashboard of your newly-created
+app, click the "Create" button and then select "Create Resources From Source Code".
+
+You will be prompted to select the repo again, and then you'll need to set up a new single resource with the following 
+settings:
+
+* **Resource Name**: "vendure-worker"
+* **Resource Type**: Worker
+* **Run Command**: `node ./dist/index-worker.js`
+
+Again you can edit the plan, and the smallest Basic plan is fine for testing purposes.
+
+No new environment variables are needed since we'll be sharing the Global variables with the worker.
+
+## Enable access to the required routes
+
+To be able to access the UI and other routes, we need to declare them first.
+
+1. In the app dashboard, click on the **Settings** tab.
+2. Click on the **vendure-server** component.
+
+   ![Open server settings](./05-open-server-settings.webp)
+
+3. Scroll down to **HTTP Request Routes**.
+4. Click on **Edit**.
+5. Click on **+ Add new route** and fill in the form like this:
+
+   ![Admin app route](./06-admin-app-route.webp)
+
+6. Make sure to check the **Preserve Path Prefix** option.
+
+You need to do this for the following routes:
+- `/admin`
+- `/assets`
+- `/health`
+- `/admin-api`
+- `/shop-api`
+
+7. Click on **Save**.
+
+## Test your Vendure server
+
+Once everything has finished deploying, you can click the app URL to open your Vendure server in a new tab. 
+
+![Open app](./07-open-app.webp)
+
+:::info
+Append `/admin` to the URL to access the admin UI, and log in with the superadmin credentials you set in the environment variables.
+:::

package/docs/guides/deployment/deploy-to-google-cloud-run/index.md

@@ -0,0 +1,53 @@
+---
+title: "Deploying to Google Cloud Run"
+images: 
+    - "/docs/deployment/deploy-to-google-cloud-run/deploy-to-gcr.webp"
+---
+
+![./deploy-to-gcr.webp](./deploy-to-gcr.webp)
+
+[Google Cloud Run](https://cloud.google.com/run) is a fully managed platform which allows you to run containerized apps and only pay while your app code is actually running.
+
+This guide was written by Martijn from [Pinelab](https://pinelab.studio/), who have been successfully running multiple Vendure projects on Google Cloud Run. The step by step commands can be found here on GitHub: 
+- https://github.com/Pinelab-studio/vendure-google-cloud-run-starter/blob/main/README.md.
+
+## Prerequisites
+This guide assumes you have:
+
+* Google cloud's `gcloud` cli installed locally
+* Created a Google Cloud project and enabled the API's we need: https://github.com/Pinelab-studio/vendure-google-cloud-run-starter/blob/main/README.md#create-a-google-cloud-project 
+
+## Setting up a MySQL database with Google Cloud SQL
+Google Cloud SQL is a fully-managed relational database service that makes it easy to set up, maintain, and manage databases in the cloud. 
+Vendure requires an SQL database to store its data, and Google Cloud SQL is a great option for this because it provides a reliable, scalable, and secure way to host our database.
+
+You can find the `gcloud` commands to create a MySQL database here: https://github.com/Pinelab-studio/vendure-google-cloud-run-starter/blob/main/README.md#create-a-mysql-database
+
+## Google Cloud Storage for assets
+Vendure stores assets such as product images on file system by default. However, Google Cloud Run does not have internal file storage, so we need to use an external storage service. 
+Google Cloud Storage is a great option for this because it provides a scalable and reliable way to store our assets in the cloud.
+
+Use these `gcloud` [commands](https://github.com/Pinelab-studio/vendure-google-cloud-run-starter/blob/main/README.md#asset-storage) to create a storage bucket for our assets.
+
+## Google Cloud Tasks for Vendure's worker
+Vendure uses a worker process to perform asynchronous tasks such as sending emails. To communicate between the main application and the worker process, we need a message queue. Google Cloud Tasks is a great option for this because it provides a fully-managed, scalable, and reliable way to send and receive messages between applications.
+
+You don't need to do anything to enable Cloud Tasks: [this plugin](https://github.com/Pinelab-studio/vendure-google-cloud-run-starter/blob/8fd342c15fa7b38e3662311f176901a5d38cde3d/src/vendure-config.ts#L88) automatically creates task queues for you.
+
+## Running locally
+Let's test out our application locally before deploying to Cloud Run. Copy [this](https://github.com/Pinelab-studio/vendure-google-cloud-run-starter/blob/main/.env.example) `.env.example` to `.env` and fill in your variables. You can skip the `WORKER_HOST` variable, because we don't have it yet.
+
+## Dockerize Vendure
+Google Cloud Run allows us to deploy containerized applications without worrying about the underlying infrastructure. To deploy Vendure to Google Cloud Run, we need to Dockerize it. Dockerizing Vendure means packaging the application and its dependencies into a container that can be easily deployed to Google Cloud Run.
+
+The setup for containerizing Vendure is already done: [This file](https://github.com/Pinelab-studio/vendure-google-cloud-run-starter/blob/main/Dockerfile) and [this file](https://github.com/Pinelab-studio/vendure-google-cloud-run-starter/blob/main/build-docker.sh) will build your container.
+
+## Deployment
+The example repository contains GitHub action definitions to automatically deploy your app to Cloud Run when you push to the `main` branch.
+
+Follow [these steps](https://github.com/Pinelab-studio/vendure-google-cloud-run-starter/blob/main/build-docker.sh) to create a service account and set your variables as repository secret in GitHub.
+
+## Keep alive
+As final improvement, you can use Google Cloud Scheduler to poll your Cloud Run instance to prevent cold starts with [this command](https://github.com/Pinelab-studio/vendure-google-cloud-run-starter/blob/main/build-docker.sh).
+
+That's it! Feel free to reach out for any questions, or create a [Pull Request in the repository](https://github.com/Pinelab-studio/vendure-google-cloud-run-starter/pulls) if you have any improvements.