Skip to content

docs(cloud): Add scloud.yaml schema reference page#627

Open
developerjamiu wants to merge 1 commit into
docs/cloud-reference-section-establishfrom
docs/cloud-reference-scloud-yaml-schema
Open

docs(cloud): Add scloud.yaml schema reference page#627
developerjamiu wants to merge 1 commit into
docs/cloud-reference-section-establishfrom
docs/cloud-reference-scloud-yaml-schema

Conversation

@developerjamiu

Copy link
Copy Markdown
Contributor

PR 14 of the Cloud IA rollout. New reference page documenting every field in scloud.yaml, plus three inbound cross-doc edits and a CLI sidebar position bump. Stacked on #620.

Page

  • cloud_docs/reference/scloud-yaml-schema.md covers the file's purpose, where it lives, the full schema with inline YAML examples per field, a complete-example pair (minimal and what scloud launch writes), the per-field rules scloud applies on subsequent launch / project link runs, and the validation error messages a reader might search for. Source-of-truth came from scloud_config_model.dart, scloud_config_io.dart, file_finder.dart, yaml_schema.dart, constants.dart, and project_files_writer.dart.

Cross-doc edits

  • reference/cli/_category_.json position bumps to 5 so CLI sits after the new schema page at 4.
  • reference/project-id-rules.md now points the scloud.yaml mention at the new schema page.
  • concepts/deployment-hooks.md cross-links to the schema's scripts section for the field types and validation rules. Also rewords the pre-existing warning lead ("pre_deploy and post_deploy failures are not symmetric:" started with inline code) to "The pre_deploy and post_deploy hooks fail asymmetrically:".
  • guides/recover-from-a-failed-deploy.md cross-links the Pre-deploy hook failure bullet to the schema's pre_deploy entry.

Test plan

  • npm run build passes
  • Open the page and verify each field section reads as a discrete entry with its inline YAML example
  • Click through the cross-links from project-id-rules.md, deployment-hooks.md, and recover-from-a-failed-deploy.md and confirm they land on the right anchors

@developerjamiu developerjamiu force-pushed the docs/cloud-reference-scloud-yaml-schema branch from 904704f to 7fcb36b Compare June 17, 2026 09:56
@developerjamiu developerjamiu requested a review from Swiftaxe June 17, 2026 09:58
@developerjamiu developerjamiu self-assigned this Jun 17, 2026
@developerjamiu developerjamiu added documentation Improvements or additions to documentation enhancement New feature or request labels Jun 17, 2026

## File location

The file lives at the root of your project: the workspace root for workspace projects, or the server package directory for single-package projects. When you run `scloud launch`, scloud creates the file in the current directory.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bugbot flags the "workspace root" as incorrect. It says the docs and the CLI default point to the server package directory. Double-check this is correct and whether it can be confusing to users so they might end up putting the file in the wrong place.


A Serverpod project deployed to Serverpod Cloud has a `scloud.yaml` file at its root. The file links the local project to a Cloud project, optionally pins the Dart SDK used for builds, and lists commands to run before or after each deploy.

scloud writes the file in two situations: `scloud launch` creates it on first setup, and `scloud project link` updates it when you point your codebase at a different Cloud project. You can also hand-edit it at any time, and scloud preserves your `dartSdk` and hook scripts across later commands. See [How scloud updates the file](#how-scloud-updates-the-file) for the exact per-field rules.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Updates it when you point your codebase at a different Cloud project" implies the file already exists. But scloud project link also creates the file from scratch — for example after scloud project create, or when a developer clones a repo and links it for the first time. Suggest:

scloud project link creates or updates it when you link your codebase to a Cloud project.


A Serverpod project deployed to Serverpod Cloud has a `scloud.yaml` file at its root. The file links the local project to a Cloud project, optionally pins the Dart SDK used for builds, and lists commands to run before or after each deploy.

scloud writes the file in two situations: `scloud launch` creates it on first setup, and `scloud project link` updates it when you point your codebase at a different Cloud project. You can also hand-edit it at any time, and scloud preserves your `dartSdk` and hook scripts across later commands. See [How scloud updates the file](#how-scloud-updates-the-file) for the exact per-field rules.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit weird to start the sentence lowercase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants