docs: clarify server deployment support

README.md

@@ -88,6 +88,25 @@ cp .valheim/dev.json.example .valheim/dev.json
 clean reference project generated with all supported module tiers enabled and
 no added gameplay code.
 
+## Server deployment
+
+Generated projects are not tied to Docker.
+
+Server deployment supports:
+
+- local filesystem destinations
+- remote POSIX servers over SSH
+- remote Windows servers over SSH
+
+Docker is optional and is used only for server lifecycle operations such as
+restart, status, and logs. Use `lifecycle.type: "none"` when HeimForge should
+deploy files without controlling the server process.
+
+Automated remote deployment requires an SSH command channel. Managed hosting
+providers that expose only FTP/SFTP or a control-panel file manager can still
+use HeimForge build and package outputs, but deployment and restart must be
+handled through the provider's tools.
+
 ## Licensing
 
 HeimForge source and documentation outside `template/` are licensed under

bootstrap/model.py

@@ -449,7 +449,7 @@ def deploy_topology_lines(model: ProjectModel) -> str:
     if model.has_client_package:
         lines.append("        +-- deploy client DLLs to Windows Valheim through /mnt/c/...")
     if model.has_server_package:
-        lines.append("        +-- deploy server DLLs to the Linux/Docker dedicated server")
+        lines.append("        +-- deploy server DLLs to the configured local or remote server")
     return "\n".join(lines)
 
 

template/README.md

@@ -34,8 +34,8 @@ For full local validation after configuring a development Valheim installation:
 ./scripts/bootstrap.sh
 ```
 
-See `docs/development.md` for local Valheim paths, server deployment, SSH,
-Docker lifecycle configuration, and reference maintenance.
+See `docs/development.md` for local setup, server deployment, and
+dependency/reference maintenance.
 
 ## Modules
 
@@ -122,6 +122,14 @@ Deployment is explicit and metadata-driven:
 
 {{DEPLOY_SIDE_NOTES_LIST}}
 
+Server deployment is not tied to Docker. Local filesystem destinations and
+remote POSIX or Windows servers over SSH are supported. Docker is an optional
+lifecycle integration for restart, status, and log operations.
+
+Managed hosts that expose only FTP/SFTP or a control-panel file manager require
+manual deployment through the provider's tools because automated remote
+deployment requires an SSH command channel.
+
 Server deployment does not restart the server unless explicitly requested.
 
 See `docs/development.md` for local and SSH deployment configuration,

template/docs/development.md

@@ -71,6 +71,28 @@ suite metadata -> server DeploymentPlan -> local or SSH deployment
 
 Changing transport never changes which modules enter the server plan. The local and SSH backends receive the same exact metadata-derived DLL list.
 
+### Choosing a server setup
+
+Docker is optional. Deployment transport and server lifecycle are configured
+independently.
+
+| Server environment | Deployment | Lifecycle |
+| --- | --- | --- |
+| Same machine or mounted filesystem | `type: "local"` | `none` or `docker` |
+| Remote POSIX server with SSH | `type: "ssh"`, `remotePlatform: "posix"` | `none` or `docker` |
+| Remote Windows server with OpenSSH | `type: "ssh"`, `remotePlatform: "windows"` | `none` or `docker` |
+| Managed host with only FTP/SFTP or a control-panel file manager | manual/provider upload | provider-managed |
+
+For SSH deployment, HeimForge requires a real remote command channel in
+addition to file transfer. The deployment process creates staging directories,
+checks the existing deployment state, verifies files, and promotes the staged
+deployment on the remote host.
+
+A hosting provider that exposes only FTP/SFTP or a file-management panel
+therefore cannot use the automated SSH deployment backend. The generated
+build/package outputs can still be uploaded through the provider's normal
+tools.
+
 ### Local transport
 
 The generated schema-v2 example uses a local suite-specific destination:

tests/bootstrap/test_model.py

@@ -181,6 +181,11 @@ def test_pending_proof_lists_omit_diagnostics_line_when_absent(self):
         self.assertNotIn("Shared Diagnostics", tokens["HARDENING_PENDING_PROOF_LIST"])
         self.assertIn("- Shared Diagnostics RPC runtime proof", token_map(build_model(make_params()))["PENDING_RUNTIME_PROOF_LIST"])
 
+    def test_deploy_topology_is_hosting_agnostic(self):
+        topology = token_map(build_model(make_params()))["DEPLOY_TOPOLOGY_LINES"]
+        self.assertIn("configured local or remote server", topology)
+        self.assertNotIn("Linux/Docker", topology)
+
     def test_deploy_side_notes_name_exactly_the_modules_that_side_receives(self):
         server_core_and_diagnostics = token_map(
             build_model(make_params(include_client=False))

tests/fixtures/test_no_stale_module_references.py

@@ -95,7 +95,7 @@ def test_operational_documents_never_name_an_omitted_module(self):
                     self.assertNotIn("./scripts/deploy-server.sh Debug", readme_lines)
                     self.assertEqual(set(), server_note_lines)
                     self.assertNotIn(
-                        "+-- deploy server DLLs to the Linux/Docker dedicated server", readme_lines
+                        "+-- deploy server DLLs to the configured local or remote server", readme_lines
                     )
                 else:
                     self.assertIn("- ServerPack", release_lines)