Using Vespa Cloud for development is easy—all you need is to register as a tenant in the Vespa Cloud console, and then build and upload your application package.
See getting started to deploy a basic sample application to Vespa Cloud, or its Java variant to deploy an application with custom Java components.
Keep reading for more details on how to develop applications using Vespa Cloud, including basic terminology, tips on using the console UI, and how to benchmark and size your application before going to production.
Developers will typically deploy their application to the
during development. Each deployment is owned by a tenant, and each specified instance is
a separate copy of the application; this lets developers work on independent copies of the same application,
or collaborate on a shared one, as they prefer—more details here.
These values can be set in the Vespa Cloud UI when deploying, or with each of the build and deploy tools,
as shown in the respective getting-started guides.
Additionally, a deployment may specify a different zone to deploy to, instead of the
dev zone; see performance testing below for how to do this.
dev are downscaled to one small node by default, so that
applications can be deployed there without changing
If you need more resources in the
dev application, set
resources explicitly by adding those tags to
see variants in services.xml.
dev zone is not for production serving, and has no uptime guarantees.
An automated Vespa software upgrade can be triggered at any time, and this may lead to some downtime if you have only one node per cluster (as with the default auto downsizing).
When using Vespa Cloud, system and tests are most easily developed using a test deployment in a
dev zone to run the tests against.
Refer to general testing guide
for a discussion of the different test types,
and the basic HTTP tests or
Java JUnit tests reference
for how to write the relevant tests.
If using the Vespa CLI to deploy and run
basic HTTP tests,
the same commands as in the test reference will just work,
provided the CLI is configured to use the
With Maven, and Java Junit tests, some additional configuration is required, to infuse the test runtime on the local machine with API and data plane credentials:
$ mvn test \ -D test.categories=system \ -D dataPlaneKeyFile=data-plane-private-key.pem -D dataPlaneCertificateFile=data-plane-public-cert.pem \ -D apiKey="$API_KEY"
apiKey is used to fetch the dev instance's endpoints.
The data plane key and certificate pair is used by
to access the application endpoint. See the Vespa Cloud API reference
for details on configuring Maven invocations. Note that the
-D vespa.test.config argument is gone;
this configuration is automatically fetched from the Vespa Cloud API—hence the need for the API key.
When running Vespa self-hosted like in the sample application, no authentication is required by default, to either API or container, and specifying a data plane key and certificate will instead cause the test to fail, since the correct SSL context is the Java default in this case.
Make sure the TestRuntime is able to start. As it will init an SSL context, make sure to remove config when running locally, in order to use a default context. Remove properties from pom.xml and IDE debug configuration.
Developers can also set these parameters in the IDE run configuration to debug system tests:
-D test.categories=system -D tenant=my_tenant -D application=my_app -D instance=my_instance -D apiKeyFile=/path/to/myname.mytenant.pem -D dataPlaneCertificateFile=data-plane-public-cert.pem -D dataPlaneKeyFile=data-plane-private-key.pem
In addition to
dev, there is also a
perf zone for performance testing.
Like production zones, this zone honors the resources specified in
the reference for how to configure them.
Performance and sizing tests can then be extrapolated to a production scenario.
In all other ways, this zone works the same way as
To deploy to
perf with Vespa CLI:
To deploy to
perf with Maven:
Read more in benchmarking.
Vespa Cloud does not allow debugging over the Java Debug Wire Protocol (JDWP) due to the protocol's inherent lack of security measures. If you need interactive debugging consider deploying your application to a self-hosted Vespa installation and manually add the JDWP agent to JVM options.
You may debug your Java code by requesting either a JVM heap dump or a Java Flight Recorder recording through the Vespa Cloud Console. Go to your application's cluster overview and select export JVM artifact on any container node. The process will take up to a few minutes. You'll find the steps to download the dump on the Console once it's completed. Extract the files from the downloaded Zstandard-compressed archive, and use the free JDK Mission Control utility to inspect the dump/recording.
Vespa Cloud upgrades daily, and applications in
also have their Vespa platform upgraded. This usually happens at the opposite time of day
of when deployments are made to each instance, and takes some minutes. Deployments without
redundancy will be unavailable during the upgrade.
Failure to deploy, due to authentication (HTTP code 401) or authorization (HTTP code 403),
is most often due to wrong configuration of
when using command line tools to deploy. Ensure the values set with Vespa CLI or in
match what is configured in the UI. For Maven, also see here for details.
In case of data plane failure,
remember to copy the public certificate to
before building and deploying. This is handled by the Vespa CLI
vespa auth cert command.
To run Java system and staging tests in an IDE,
ensure all API and data plane keys and certificates are configured in the IDE as well;
not all IDEs pick up all settings from
-Dtest.categories=system -DapiKeyFile=/path-to/tname.pem -DdataPlaneCertificateFile=/path-to/data-plane-public-cert.pem -DdataPlaneKeyFile=/path-to/data-plane-private-key.pem