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
Copy file name to clipboardExpand all lines: development/satellite/process-management.mdx
+18-1Lines changed: 18 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -116,6 +116,10 @@ All communication uses newline-delimited JSON following JSON-RPC 2.0 specificati
116
116
**Idle Process Management**: Processes that remain inactive for extended periods are automatically terminated and respawned on-demand to optimize memory usage. See [Idle Process Management](/development/satellite/idle-process-management) for details on automatic termination, dormant state tracking, and respawning.
117
117
</Info>
118
118
119
+
<Info>
120
+
**Configuration Updates**: When a user updates their MCP server configuration (args, env) via the dashboard, the backend sends a configure command to the satellite. For stdio servers, the satellite automatically restarts the process with the new configuration. See [Backend Communication](/development/satellite/backend-communication) for the command flow.
121
+
</Info>
122
+
119
123
### Lifecycle States
120
124
121
125
**starting:**
@@ -161,7 +165,7 @@ Process termination follows a two-phase graceful shutdown approach to ensure cle
161
165
162
166
#### Termination Types
163
167
164
-
The system handles three types of intentional terminations differently:
168
+
The system handles four types of intentional terminations differently:
165
169
166
170
**1. Manual Termination**
167
171
- Triggered by explicit restart or stop commands
@@ -184,6 +188,19 @@ The system handles three types of intentional terminations differently:
184
188
- No auto-restart triggered (intentional removal)
185
189
- Invoked via `removeServerCompletely()` method
186
190
191
+
**4. Configuration Update Restart**
192
+
- Triggered when stdio server configuration is modified (e.g., user args change)
193
+
- Detected via `DynamicConfigManager` comparing old vs new configuration
194
+
- Existing process terminated with graceful shutdown
195
+
- Tools cleared from cache via `stdioToolDiscoveryManager.clearServerTools()`
196
+
- New process spawned with updated configuration (new args, env)
197
+
- Tool discovery runs automatically on the new process
198
+
- Enables real-time configuration updates without satellite restart
199
+
200
+
<Info>
201
+
**HTTP/SSE Servers**: Unlike stdio servers, HTTP/SSE servers don't require restart on config changes. Their configuration (headers, query params, URL) is read fresh on each request, so updates are immediate.
202
+
</Info>
203
+
187
204
#### Crash Detection vs Intentional Shutdown
188
205
189
206
The system distinguishes between crashes and intentional shutdowns:
The satellite must join the same network as the backend. Find your network name:
150
+
```bash
151
+
docker network ls | grep deploystack
152
+
```
153
+
154
+
You'll see something like `docker-compose_deploystack-network` or similar. Use this name in the next step.
155
+
156
+
4.**Deploy Satellite with Docker**:
157
+
158
+
<Warning>
159
+
The satellite requires a running backend. If the backend is not reachable, the satellite will exit immediately. Make sure `docker-compose ps` shows the backend as healthy before proceeding.
160
+
</Warning>
148
161
149
162
**For local development (connecting from same machine):**
@@ -181,12 +194,14 @@ The satellite must be deployed separately after completing the setup wizard:
181
194
- Required for OAuth authentication to work with remote MCP clients
182
195
</Info>
183
196
184
-
4.**Verify Satellite Registration**:
197
+
5.**Verify Satellite Registration**:
185
198
```bash
186
-
docker logs deploystack-satellite
199
+
docker logs <container-id>
187
200
# Should show: ✅ Satellite registered successfully: docker-satellite-001
188
201
```
189
202
203
+
Get the container ID from `docker ps`.
204
+
190
205
<Info>
191
206
**Note**: After initial registration, the satellite saves its API key to persistent storage. The registration token is only needed for the first startup. Container restarts will use the saved API key automatically.
When opening the frontend, you will be redirected to `http://localhost:8080/login`
51
+
- Go to "Create Account" to set up your admin user ([read more about user types](/roles))
52
+
- Login with your new admin account
53
53
</Step>
54
54
55
55
<Steptitle="Deploy Satellite">
56
-
After completing the setup wizard, proceed to the [Satellite Service](#satellite-service) section below to deploy your first satellite and start managing MCP servers.
56
+
After creating your admin account, proceed to the [Satellite Service](#satellite-service) section below to deploy your first satellite and start managing MCP servers.
57
57
</Step>
58
58
</Steps>
59
59
@@ -209,25 +209,43 @@ After completing the basic backend and frontend setup, deploy at least one satel
209
209
The token format will be: `deploystack_satellite_global_eyJhbGciOi...`
210
210
</Step>
211
211
212
+
<Steptitle="Find Docker Network">
213
+
The satellite must join the same Docker network as the backend. Find your network name:
214
+
215
+
```bash
216
+
docker network ls | grep deploystack
217
+
```
218
+
219
+
You'll see something like `docker-compose_deploystack-network` or similar. Use this name in the next step.
220
+
</Step>
221
+
212
222
<Steptitle="Start Satellite Service">
223
+
<Warning>
224
+
The satellite requires a running backend. If the backend is not reachable, the satellite will exit immediately. Make sure the backend is running before proceeding.
225
+
</Warning>
226
+
213
227
**For local development (connecting from same machine):**
0 commit comments