You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Configuration for Spin application features such as [application variables](./variables),
27
+
You can change the configuration for Spin application features such as [application variables](./variables),
27
28
[key value storage](./kv-store-api-guide), [SQL storage](./sqlite-api-guide)
28
-
and [Serverless AI](./serverless-ai-api-guide)can be supplied dynamically, i.e. during the application runtime,
29
+
and [Serverless AI](./serverless-ai-api-guide)at the time you run the application,
29
30
requiring no changes to the application code itself.
30
31
31
-
This runtime configuration data is stored in the `runtime-config.toml` file and passed in via the `--runtime-config-file` flag
32
-
when invoking the `spin up` command.
32
+
This runtime configuration data is stored in the `runtime-config.toml` file and passed to `spin up` via the `--runtime-config-file` flag.
33
+
34
+
{{ details "Why do I need to specify `--runtime-config-file` rather than Spin detecting it automatically?" "Spin uses safe, local defaults for saving your data. The runtime config file can override those. It should be up to you to opt into that override." }}
33
35
34
36
Let's look at each configuration category in-depth below.
35
37
36
38
## Application Variables Runtime Configuration
37
39
38
-
[Application Variables](./variables) values may be set at runtime by providers. Currently,
39
-
there are three application variable providers: the [environment-variable provider](#environment-variable-provider),
40
-
the [Vault provider](#vault-application-variable-provider) and the [Azure Key Vault provider](#azure-key-vault-application-variable-provider).
40
+
When an application needs the value of an [application variable](./variables), it obtains it from a provider. By default, the only provider Spin considers is the [environment variables provider](#environment-variable-provider). That is, application variables are derived from the environment variables of the Spin process.
41
+
42
+
You can also tell Spin to use the [Vault provider](#vault-application-variable-provider) and/or the [Azure Key Vault provider](#azure-key-vault-application-variable-provider), by setting these up in the runtime config file.
41
43
42
-
Multiple application variable providers can be configured in Spin. Providers are
43
-
prioritized top-down in the runtime configuration file, with higher-listed providers
44
-
taking precedence. The environment variable provider always has the highest
45
-
priority.
44
+
You can tell Spin to use multiple application variable providers. Spin prioritises them in the order they appear in the runtime config file, with higher-listed providers
45
+
taking precedence. The environment variable provider always has the highest priority.
46
46
47
47
The provider examples below show how to use or configure each
48
48
provider. For examples on how to access these variables values within your application, see
Spin provides built-in key-value storage. By default, this storage is backed by a file in the application `.spin` directory. However, the Spin runtime configuration file (`runtime-config.toml`) can be updated to not only modify the file configuration but also choose to use a different backing store. The available store options are the file provider, an external Redis database, Azure CosmosDB or AWS DynamoDB.
239
+
Spin provides built-in key-value storage. By default, this storage is backed by a file in the application `.spin` directory. However, you can use the Spin runtime configuration file (`runtime-config.toml`) to modify the file location, or to use a different backing store. The available store options are the file provider, an external Redis database, Azure CosmosDB or AWS DynamoDB.
240
240
241
241
### File Key Value Store Provider
242
242
@@ -367,7 +367,7 @@ By default, components will not have access to any of these databases (even the
367
367
368
368
## LLM Runtime Configuration
369
369
370
-
Spin provides a Large Language Model interface for interacting with LLMs for inferencing and embedding. The default host implementation is to use local CPU/GPU compute. However, the Spin runtime configuration file (`runtime-config.toml`) can be updated to enable Spin to use remote compute using HTTP requests.
370
+
Spin provides a Large Language Model interface for interacting with LLMs for inferencing and embedding. The default host implementation is to use local CPU/GPU compute. However, you can use the Spin runtime configuration file (`runtime-config.toml`) to direct Spin to use remote compute using HTTP requests.
371
371
372
372
### Remote Compute Provider
373
373
@@ -380,6 +380,8 @@ url = "http://example.com"
380
380
auth_token = "<auth_token>"
381
381
```
382
382
383
-
Currently, the remote compute option requires an user to deploy their own LLM proxy service. Fermyon Cloud users can do this using the [`cloud-gpu` plugin](https://github.com/fermyon/spin-cloud-gpu). If you prefer to create and deploy your own proxy service, you can find a reference implementation of the proxy protocol in the [`spin-cloud-gpu plugin repository`](https://github.com/fermyon/spin-cloud-gpu/blob/main/fermyon-cloud-gpu/src/index.ts).
383
+
Currently, the remote compute option requires an user to deploy their own LLM proxy service. You can find a reference implementation of a proxy service in the [`spin-cloud-gpu plugin repository`](https://github.com/fermyon/spin-cloud-gpu/blob/main/fermyon-cloud-gpu/src/index.ts).
384
+
385
+
> If you have a Fermyon Cloud account, you can deploy a proxy service there using the [`cloud-gpu` plugin](https://github.com/fermyon/spin-cloud-gpu).
384
386
385
387
By default, components will not have access to the LLM models unless granted explicit access through the `component.ai_models` entry in the component manifest within `spin.toml`. See [Serverless AI](./serverless-ai-api-guide) for more details.
Copy file name to clipboardExpand all lines: content/v3/manifest-reference-v1.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -35,7 +35,7 @@ The manifest is a TOML file, and follows standard TOML syntax. See the [TOML do
35
35
|`description`| Optional | String | A human-readable description of the application. |`"The best app for all your world-greeting needs"`|
36
36
|`authors`| Optional | Array of strings | The authors of the applications. If present, this must ba an array, even if it has only one entry. |`["Jane Q Hacker (<[email protected]>)"]`|
37
37
|`trigger`| Required | Table | The trigger for the application - that is, the kind of event that the application responds to. The table must contain the `type` field, and may contain others depending on the value of `type`. See [The `trigger` Table](#the-trigger-table) for details. |`{ type = "http" }`|
38
-
|`variables`| Optional | Table |Dynamic configuration variables which the user can set when they run the application. See [The `variables` Table](#the-variables-table) below. |`[variables]`<br />`message = { default = "hello" }`|
38
+
|`variables`| Optional | Table |Application configuration variables which the user can set when they run the application. See [The `variables` Table](#the-variables-table) below. |`[variables]`<br />`message = { default = "hello" }`|
39
39
|`component`| Required | Table array | A manifest must contain at least one `component` table. `component` is always an array, even if there is only one component, so always use double square brackets. See [The `component` Tables](#the-component-tables) below. |`[[component]]`<br />`id = "hello"`|
40
40
41
41
## The `trigger` Table
@@ -110,7 +110,7 @@ Each table in the `component` array contains the following fields:
110
110
|`environment`| Optional | Table | Environment variables to be set for the Wasm module. This is a table. The table keys are user-defined; the values must be strings. |`{ DB_URL = "mysql://spin:spin@localhost/dev" }`|
111
111
|`trigger`| Required | Table | Specifies how this component is triggered. This is a table, whose contents of are trigger-specific; see below. |`[component.trigger]`<br />`route = "/..."`|
112
112
|`build`| Optional | Table | The command that `spin build` uses to build this component. See [The `component.build` Table](#the-componentbuild-table) below. |`[component.build]`<br />`command = "npm run build"`|
113
-
|`config`| Optional | Table |Dynamic configuration values to be made available to this component. The table keys are user-defined; the values must be strings, and may use template notation as described under [Dynamic Configuration](dynamic-configuration). |`[component.config]`<br />`api_base_url = "https://{{ api_host }}/v1"`|
113
+
|`config`| Optional | Table |Application configuration values to be made available to this component. The table keys are user-defined; the values must be strings, and may use template notation as described under [Application Variables](variables#adding-variables-to-your-applications). |`[component.config]`<br />`api_base_url = "https://{{ api_host }}/v1"`|
114
114
115
115
### The `component.trigger` Table for HTTP Applications
|`spin_manifest_version`| Required | Number | The version of the file format that the rest of the manifest follows. For manifests using this format, this value must be `2`. |`2`|
72
72
|`application`| Required | Table | Information about the application and application-global options. See [The `application` Table](#the-application-table) below. |`[application]`<br />`name = "greetings"`<br />`version = "1.0.0"`|
73
-
|`variables`| Optional | Table |Dynamic configuration variables which the user can set when they run the application. See [The `variables` Table](#the-variables-table) below. |`[variables]`<br />`message = { default = "hello" }`|
73
+
|`variables`| Optional | Table |Application configuration variables which the user can set when they run the application. See [The `variables` Table](#the-variables-table) below. |`[variables]`<br />`message = { default = "hello" }`|
74
74
|`trigger`| Required | Table | Associates triggers and conditions to the components that handle them - for example, mapping a HTTP route to a handling component. See [The `trigger` Table](#the-trigger-table) below. |`[[trigger.http]]`<br />`component = "greeter"`<br />`route = "/greet"`|
75
75
|`component`| Required | Table | The WebAssembly components that make up the application, together with whatever configuration and resources they depend on, such as asset files or storage access. See [The `component` Table](#the-component-table) below. |`[component.greeter]`<br />`source = "greeting_manager.wasm"`<br />`files = ["confetti.jpg"]`|
76
76
@@ -180,7 +180,7 @@ The value of each key is a table with the following fields.
180
180
|`key_value_stores`| Optional | Array of strings | An array of key-value stores that the Wasm module is allowed to read or write. A store named `default` is provided by the Spin runtime, though modules must still be permitted to access it. In current versions of Spin, `"default"` is the only store allowed. |`["default"]`|
181
181
|`environment`| Optional | Table | Environment variables to be set for the Wasm module. This is a table. The table keys are user-defined; the values must be strings. |`{ DB_URL = "mysql://spin:spin@localhost/dev" }`|
182
182
|`build`| Optional | Table | The command that `spin build` uses to build this component. See [The `component.(id).build` Table](#the-componentidbuild-table) below. |`[component.cart.build]`<br />`command = "npm run build"`|
183
-
|`variables`| Optional | Table |Dynamic configuration values to be made available to this component. The table keys are user-defined; the values must be strings, and may use template notation as described under [Dynamic Configuration](dynamic-configuration). |`[component.cart.variables]`<br />`api_base_url = "https://{{ api_host }}/v1"`|
183
+
|`variables`| Optional | Table |Application configuration values to be made available to this component. The table keys are user-defined; the values must be strings, and may use template notation as described under [Application Variables](variables#adding-variables-to-your-applications). |`[component.cart.variables]`<br />`api_base_url = "https://{{ api_host }}/v1"`|
184
184
|`dependencies_inherit_configuration`| Optional | Boolean | If true, dependencies can invoke Spin APIs with the same permissions as the main component. If false, dependencies have no permissions (e.g. network, key-value stores, SQLite databases). The default is false. |`false`|
185
185
|`dependencies`| Optional | Table | Specifies how to satisfy Wasm Component Model imports of this component. See [Using Component Dependencies](writing-apps.md#using-component-dependencies). |`[component.cart.dependencies]`<br />`"example:calculator/adder" = { registry = "example.com", package = "example:adding-calculator", version = "1.0.0" }`|
Copy file name to clipboardExpand all lines: content/v3/variables.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ Spin supports dynamic application variables. Instead of being static, their valu
14
14
15
15
These variables are defined in a Spin application manifest (in the `[variables]` section), and their values can be set or overridden at runtime by an [application variables provider](./dynamic-configuration.md#application-variables-runtime-configuration). When running Spin locally, the variables provider can be [Hashicorp Vault](./dynamic-configuration.md#vault-application-variable-provider) for secrets, [Azure Key Vault](https://azure.microsoft.com/en-us/products/key-vault), or host environment variables.
16
16
17
-
For information about configuring application variables providers, refer to the [dynamic configuration documentation](./dynamic-configuration.md#application-variables-runtime-configuration).
17
+
For information about configuring application variables providers, refer to the [runtime configuration documentation](./dynamic-configuration.md#application-variables-runtime-configuration).
18
18
19
19
## Adding Variables to Your Applications
20
20
@@ -47,7 +47,7 @@ api_version = "v1"
47
47
48
48
When a component variable references an application variable, its value will dynamically update as the application variable changes. For example, if the `api_token` variable is provided using the [Spin Vault provider](./dynamic-configuration.md#vault-application-variable-provider), it can be updated by changing the value in HashiCorp Vault. The next time the component gets the value of `token`, the latest value of `api_token` will be returned by the provider. See the [next section](#using-variables-from-applications) to learn how to use Spin's configuration SDKs to get configuration variables within applications.
49
49
50
-
Variables can also be used in other sections of the application manifest that benefit from dynamic configuration. In these cases, the variables are substituted at application load time rather than dynamically updated while the application is running. For example, the `allowed_outbound_hosts` can be dynamically configured using variables as follows:
50
+
Variables can also be used in other sections of the application manifest that benefit from runtime configuration. In these cases, the variables are substituted at application load time rather than dynamically updated while the application is running. For example, the `allowed_outbound_hosts` can be dynamically configured using variables as follows:
0 commit comments