diff --git a/docs/docs/20-usage/20-workflow-syntax.md b/docs/docs/20-usage/20-workflow-syntax.md
index 5c13bff04..729c02f75 100644
--- a/docs/docs/20-usage/20-workflow-syntax.md
+++ b/docs/docs/20-usage/20-workflow-syntax.md
@@ -179,12 +179,6 @@ Woodpecker provides the ability to pass environment variables to individual step
 
 For more details, check the [environment docs](./50-environment.md).
 
-### `secrets`
-
-Woodpecker provides the ability to store named parameters external to the YAML configuration file, in a central secret store. These secrets can be passed to individual steps of the workflow at runtime.
-
-For more details, check the [secrets docs](./40-secrets.md).
-
 ### `failure`
 
 Some of the steps may be allowed to fail without causing the whole workflow and therefore pipeline to report a failure (e.g., a step executing a linting check). To enable this, add `failure: ignore` to your step. If Woodpecker encounters an error while executing the step, it will report it as failed but still executes the next steps of the workflow, if any, without affecting the status of the workflow.
diff --git a/docs/docs/20-usage/40-secrets.md b/docs/docs/20-usage/40-secrets.md
index aadb7734d..2c7065815 100644
--- a/docs/docs/20-usage/40-secrets.md
+++ b/docs/docs/20-usage/40-secrets.md
@@ -11,26 +11,7 @@ Woodpecker provides three different levels to add secrets to your pipeline. The
 
 ## Usage
 
-### Use secrets in commands
-
-Secrets are exposed to your pipeline steps and plugins as uppercase environment variables and can therefore be referenced in the commands section of your pipeline,
-once their usage is declared in the `secrets` section:
-
-```diff
- steps:
-   - name: docker
-     image: docker
-     commands:
-+      - echo $docker_username
-+      - echo $DOCKER_PASSWORD
-+    secrets: [ docker_username, DOCKER_PASSWORD ]
-```
-
-The case of the environment variables is not changed, but secret matching is done case-insensitively. In the example above, `DOCKER_PASSWORD` would also match if the secret is called `docker_password`.
-
-### Use secrets in settings and environment
-
-You can set an setting or environment value from secrets using the `from_secret` syntax.
+You can set a setting or an environment value from secrets using the `from_secret` syntax.
 
 In this example, the secret named `secret_token` would be passed to the setting named `token`,which will be available in the plugin as environment variable named `PLUGIN_TOKEN` (See [plugins](./51-plugins/20-creating-plugins.md#settings) for details), and to the environment variable `TOKEN_ENV`.
 
@@ -55,11 +36,11 @@ Please note parameter expressions are subject to pre-processing. When using secr
    - name: docker
      image: docker
      commands:
--      - echo ${docker_username}
--      - echo ${DOCKER_PASSWORD}
-+      - echo $${docker_username}
-+      - echo $${DOCKER_PASSWORD}
-     secrets: [ docker_username, DOCKER_PASSWORD ]
+-      - echo ${TOKEN_ENV}
++      - echo $${TOKEN_ENV}
+     environment:
+       TOKEN_ENV:
+         from_secret: secret_token
 ```
 
 ### Use in Pull Requests events
diff --git a/docs/docs/20-usage/51-plugins/20-creating-plugins.md b/docs/docs/20-usage/51-plugins/20-creating-plugins.md
index c09a6226d..4591a1d1a 100644
--- a/docs/docs/20-usage/51-plugins/20-creating-plugins.md
+++ b/docs/docs/20-usage/51-plugins/20-creating-plugins.md
@@ -42,7 +42,7 @@ Values like this are converted to JSON and then passed to your plugin. In the ex
 
 ### Secrets
 
-Secrets should be passed as settings too. Therefore, users should use [`from_secret`](../40-secrets.md#use-secrets-in-settings-and-environment).
+Secrets should be passed as settings too. Therefore, users should use [`from_secret`](../40-secrets.md#usage).
 
 ## Plugin library
 
diff --git a/docs/docs/20-usage/51-plugins/51-overview.md b/docs/docs/20-usage/51-plugins/51-overview.md
index 1599b8cca..ea43d66e7 100644
--- a/docs/docs/20-usage/51-plugins/51-overview.md
+++ b/docs/docs/20-usage/51-plugins/51-overview.md
@@ -52,7 +52,7 @@ While normal steps are all about arbitrary code execution, plugins should only a
 
 That's why there are a few limitations. The workspace base is always mounted at `/woodpecker`, but the working directory is dynamically
 adjusted accordingly, as user of a plugin you should not have to care about this. Also, you cannot use the plugin together with `commands`
-or `entrypoint` which will fail. Using `secrets` or `environment` is possible, but in this case, the plugin is internally not treated as plugin
+or `entrypoint` which will fail. Using `environment` is possible, but in this case, the plugin is internally not treated as plugin
 anymore. The container then cannot access secrets with plugin filter anymore and the containers won't be privileged without explicit definition.
 
 ## Finding Plugins
diff --git a/docs/docs/91-migrations.md b/docs/docs/91-migrations.md
index 221358035..90d31cfd4 100644
--- a/docs/docs/91-migrations.md
+++ b/docs/docs/91-migrations.md
@@ -25,7 +25,7 @@ Some versions need some changes to the server configuration or the pipeline conf
 - Pipelines without a config file will now be skipped instead of failing
 - Removed implicitly defined `regcred` image pull secret name. Set it explicitly via `WOODPECKER_BACKEND_K8S_PULL_SECRET_NAMES`
 - Removed `includes` and `excludes` support from **event** filter
-- Removed uppercasing all secret env vars, instead, the value of the `secrets` property is used. [Read more](./20-usage/40-secrets.md#use-secrets-in-commands)
+- Removed uppercasing all secret env vars, instead, the value of the `secrets` property is used. [Read more](./20-usage/40-secrets.md#usage)
 - Removed alternative names for secrets, use `environment` with `from_secret`
 - Removed slice definition for env vars
 - Removed `environment` filter, use `when.evaluate`
@@ -38,6 +38,7 @@ Some versions need some changes to the server configuration or the pipeline conf
 - Removed old API routes: `registry/` -> `registries`, `/authorize/token`
 - Replaced `registry` command with `repo registry` in cli
 - Disallow upgrades from 1.x, upgrade to 2.x first
+- Deprecated `secrets`, use `environment` with `from_secret`
 
 ## 2.0.0
 
diff --git a/pipeline/frontend/yaml/linter/linter.go b/pipeline/frontend/yaml/linter/linter.go
index f717736ad..e199100e7 100644
--- a/pipeline/frontend/yaml/linter/linter.go
+++ b/pipeline/frontend/yaml/linter/linter.go
@@ -265,6 +265,21 @@ func (l *Linter) lintDeprecations(config *WorkflowConfig) (err error) {
 		return err
 	}
 
+	for _, container := range parsed.Steps.ContainerList {
+		if len(container.Secrets) > 0 {
+			err = multierr.Append(err, &errorTypes.PipelineError{
+				Type:    errorTypes.PipelineErrorTypeDeprecation,
+				Message: "Secrets are deprecated, use environment with from_secret",
+				Data: errors.DeprecationErrorData{
+					File:  config.File,
+					Field: fmt.Sprintf("steps.%s.secrets", container.Name),
+					Docs:  "https://woodpecker-ci.org/docs/usage/secrets#usage",
+				},
+				IsWarning: true,
+			})
+		}
+	}
+
 	return nil
 }
 
diff --git a/pipeline/frontend/yaml/types/container.go b/pipeline/frontend/yaml/types/container.go
index ff5d72438..8d2bbbf64 100644
--- a/pipeline/frontend/yaml/types/container.go
+++ b/pipeline/frontend/yaml/types/container.go
@@ -47,9 +47,11 @@ type (
 		Ports          []string           `yaml:"ports,omitempty"`
 		DependsOn      base.StringOrSlice `yaml:"depends_on,omitempty"`
 
-		Secrets     []string       `yaml:"secrets,omitempty"`
 		Environment map[string]any `yaml:"environment,omitempty"`
 
+		// Deprecated
+		Secrets []string `yaml:"secrets,omitempty"`
+
 		// Docker and Kubernetes Specific
 		Privileged bool `yaml:"privileged,omitempty"`