An application can be deployed to a zone, which is a combination of an environment and a region. This explains the rules governing the various environments. A list of all zones is also available.
| Name | Description | Expiry | Cluster sizes |
|---|---|---|---|
dev |
Used for manual development testing. | 7 days | 1 |
perf |
Used for manual performance testing. | 7 days | min(3, spec) |
test |
Used for automated system tests. | - | 1 |
staging |
Used for automated staging tests. | - | min(max(2, 0.1 * spec), spec) |
prod |
Hosts all production deployments. | No expiry | max(2, spec) |
Deployments in prod must have at least one more node than required to handle peak load.
A cluster is a container or content cluster,
and a regular application has a container and a content cluster.
A minimal, typical prod deployment therefore has 4 nodes.
dev and perf are deployed to directly as part of development or testing.
dev and perf expire after 7 days of inactivity,
i.e., 7 days after running deploy.
This applies to all plans, not only the Free Trial.
Use the Vespa Console to extend the expiry period, or redeploy the application to add 7 more days.
To make it convenient to deploy applications from prod to dev and perf without modification, resources are automatically downscaled in these zones. To control the resources you get in these zones, specify them explicitly for the environment in question (dev or perf) as described in deployment variants.
To deploy to the perf environment, use
mvn package vespa:deploy -Denvironment=perf
In dev and perf, the latest active Vespa version is used when deploying.
A dev instance is upgraded at a time which is most likely at night for the developer (based on
time when last deployments were made). A perf instance is also upgraded at a time which is most
likely night. An upgrade will be skipped if metrics indicate ongoing feed or query
load, but will still be done if current version is more than a week old.