Capabilities
Scopes can be configured to have specific hardware (eg: CPU or GPU, storage) and configurations (eg: healthcheck URL, log throttling).
We encourage you to provide as little scope specs and constraints as possible since this allows greater flexibility towards automated runtime optimization and cost savings. For example, if you establish a specific instance type, we won't be able to swap your instance type for a more suitable one that better suits your workload.
How to set capabilities
Capabilities can be set both at creation or while the scope is active through the "Advanced" section at the bottom of the new/edit scope section.
Use the /capability endpoint to list the available capabilities and the /scope/:id endpoint to check the current
configuration (under the capabilities field). Capabilities are defined using JSON Schema.
Check our API section for a complete reference on how to set capabilities.
Capability Lists
Language & Runtime (Serverless only)
Here you have to specify what's the language runtime that will run your serverless applications.
Processor (server-based only)
Here you can choose between traditional CPU instances or CPU + GPU, which are handy for example to serve machine-learned models. In case you really know what you're doing, you ultimately have the ability to specify the exact instance type that this scope will require.
Scaling (server-based only)
Here you configure which is the min and max amount of instances that will serve your application in this scope. We recommend never going below 2 and being careful about the maximum value since it can compete account-wide quotas.
Here you can also control the scaling behavior, making your instances scale up and down depending on the average CPU that it is consuming.
Spot instances (server-based only)
When you enable spot instances you have the chance of competing for lower-priced resources by taking the risk of being evicted from those instances. To properly manage this tradeoff you can choose which percentage of your scope will be targeted to run on spot instances.
Function Handler (serverless only)
Specifies which function is being exported for the runtime to invoke upon a call.
Storage
In the case of server-based applications, this capability is controlling the amount of storage that will be available on the mounted filesystem.
Timeout (serverless only)
Determines how many seconds your serverless function can run before being considered 'failed'.
Continuous Delivery
When you turn on this capability you have to specify which are the branches that will be automatically deployed into this scope. Whenever there's a new build coming from any of these branches we will generate an automatic release and run an all-in deployment it into this scope.
Turning on continuous delivery in production scopes can be dangerous as this is an all-in deployment without a progressive traffic switching step. Use with care.
You can use this capability to automatically deploy on this scope every
Logs (server-based only)
Here you can select the log service provider and set up scope-specific policies such as logs throttling.
Metrics (server-based only)
In this section you can turn on / off the functionalities that extract metrics from your instance to deliver them to Cloud Watch.
Metrics and logs are embedded in nullplatform's product and turning them off will have an impact in your experience harm your troubleshooting capabilities.