This section goes through serverless deployment of an indexing project (squid) to Subsquid Cloud.
The deployment is managed by the file
squid.yaml in the root folder of the squid and defines:
- squid name and version
- which services should be deployed for the squid (e.g. postgres, processor, api, RPC proxy)
- what resources should be allocated by Cloud for each squid service (only configurable if you deploy to a Professional organization)
Make sure to check our best practices guide before deploying to production!
Consider our RPC proxy service if your squid requires an endpoint.
0. Install Squid CLI
Follow this guide, including the optional authentication steps.
The manifest-based deployment flow below was introduced in
Follow the migration guide to upgrade from older versions of
1. Inspect and deploy using the manifest
Navigate to the squid folder and make sure
squid.yaml is present in the root. See the Deploy Manifest page for a full reference.
To deploy a new version or update the existing one (define in the manifest), run
sqd deploy .
For a full list of available deploy options, inspect
sqd deploy help.
By default your squid will be deployed as collocated. Collocated squids are intended for development and prototyping only. They share resources with each other and may have stability issues. For production we strongly recommend to deploy your squids as dedicated instead.
2. Monitor Squid logs
Once the squid is deployed, the GraphQL endpoint is available straight away. Normally one should wait until the squid has processed all historical blocks and is fully in sync.
To inspect the squid logs run
sqd logs my-new-squid@v0 -f
See the logging page for more details on how to inspect logs with
You can also read logs on the squid page in Cloud. The page also has credentials for direct database access and some metrics visualizations.