> ## Documentation Index
> Fetch the complete documentation index at: https://docs.doploy.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Setting Up Staging Instance

> Configure a staging environment for testing before production

# Setting Up Staging Instance

Learn how to set up a staging instance for testing changes before deploying to production.

## Why Use Staging?

Staging instances provide a pre-production environment where you can:

* **Test changes safely** - Verify new features and customizations before production
* **QA and client demos** - Show stakeholders changes without affecting production, and let them test it themselves
* **Test with production data** - Restore production backups to test with real data in a safe, neutralized environment - (no emails sent)
* **Catch issues early** - Identify problems before they reach your live environment

## Prerequisites

Before creating a staging instance, ensure you have:

* **Active subscription** - Staging deployments require a Pro or Starter plan subscription
* **Server ready** - A server must be available and fully provisioned (check status in [Servers](/servers/doploy-servers))
* **Git branch** - Your staging code should be committed to a Git branch (typically `staging` or `develop`)

## Important Considerations

**Multiple Staging Instances**\
Unlike production (which allows only one instance), you can create multiple staging instances at no additional cost.

**Server Separation**\
For optimal performance and to minimize risk to production, deploy staging on a server separate from the production instance.

**No Automatic Backups**\
You can manually create backups of your staging database or restore from production backups as needed.

## Step 1: Create Staging Instance

Navigate to your project's Deployments page and click the **"+"** button next to **Staging**.

### Select Server

Choose which server to host your staging instance. For best practices:

* Use a separate server from production when possible
* Consider using the same server as production only for small projects or testing
* Ensure adequate resources for your staging workload

If no servers are available, you'll need to [add a server](/servers/doploy-servers) first.

### Select Branch

Select the Git branch with your staging Odoo modules and customizations. This is typically your `staging` or `develop` branch.

You can also create a new branch by clicking the **"Branch"** button, which lets you base it on an existing branch.

### Configure Domain

Choose how users will access your staging instance:

**Free doploy subdomain**\
Use a `{your-name}.doploy.site` domain. This is automatically available and requires no DNS configuration.

**Custom domain**\
If using your own domain, doploy will display the server IP address and DNS setup instructions. Create an A record pointing your domain to this IP address before deployment. doploy will handle the SSL certificate for your custom domain automatically.

### Database Name

A database name is auto-generated based on your branch name and a random suffix, ensuring uniqueness. You can modify this if needed, but it must be a valid PostgreSQL identifier (letters, numbers, underscores only).

### Admin Password

A secure random password is automatically generated for the Odoo admin user.

**Important:** Save this password immediately—it won't be shown again. You can change it later from within Odoo or [reset it via doploy](/managing-odoo/reset-admin-password).

## Step 2: Deploy

Review your configuration and click **"Deploy Instance"** to start the deployment process.

The instance will be built and deployed, typically completing within a few minutes. You can monitor progress in the deployment history tab.

## Step 3: Configure Domain DNS (Custom Domains Only)

If you're using a custom domain, configure your DNS records before the deployment completes:

1. Create an A record for your domain
2. Point it to the server IP address shown in the deployment modal
3. Wait for DNS propagation (usually 5-60 minutes)

SSL certificates are automatically provisioned once DNS is configured correctly.

## Using Production Data in Staging

After your staging instance is deployed, you can restore a production backup to test with real data:

1. Go to the **Backups** tab in your staging instance
2. Click **Restore from Backup**
3. Select a backup from your production instance
4. The data will be automatically neutralized (emails disabled) to prevent accidental actions

This allows you to test changes against real data without affecting production.

## Staging Workflow

**Testing Changes**

1. Make changes in your staging branch
2. The staging instance will automatically rebuild with your changes
3. Test thoroughly in staging before merging to production

**Promoting to Production**

1. Once changes are tested and validated in staging
2. Merge your staging branch into your production branch
3. Your production instance will automatically rebuild with the changes

## Best Practices

**Keep Staging Close to Production**\
Regularly sync staging data from production backups to ensure your staging environment closely mirrors production.

**Test Before Production**\
Always test changes in staging before deploying to production. This helps catch issues early.

**Use Separate Servers**\
When possible, run staging on a separate server from production to avoid resource contention.

## Next Steps

* [Set up production instance](/managing-odoo/production-instance) for your live environment
* [Set up developer instance](/managing-odoo/developer-instance) for automated testing
* [Configure automatic backups](/getting-started/backup-schedule) for production
* [Set up DNS](/getting-started/dns-setup) for your custom domain