- Home
- Skills
- Trentshaines
- Dotfiles
- Trent Local Server Prod
trent-local-server-prod_skill
- Shell
0
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
3 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill trentshaines/dotfiles --skill trent-local-server-prod- skill.md1.9 KB
Overview
This skill deploys a local development environment that points to the production configuration (DECAGON_ENV=prod). It launches backend and frontend processes in separate tmux panes so you can run, test, and iterate locally while targeting production resources. The original tmux pane stays available for other commands.
How this skill works
The skill automates splitting the current tmux window into three panes and runs the backend and frontend dev servers with DECAGON_ENV=prod. It installs backend Python requirements and starts uvicorn with reload enabled, and starts the Next.js frontend dev server with yarn. Pane IDs are captured and used to send commands reliably.
When to use it
- You need to test local changes against production services or data.
- You want to run backend and frontend concurrently while pointing both to prod.
- You need hot-reload backend while evaluating production environment behavior.
- You prefer using tmux to manage persistent panes for dev workflows.
- You must keep an interactive pane available for debugging or auxiliary commands.
Best practices
- Run this from the project root so relative paths (backend/, frontend/) resolve correctly.
- Ensure tmux is installed and you are inside a tmux session before running pane-splitting commands.
- Verify credentials and access to production resources are appropriate and safe for local testing.
- Use the original pane for monitoring logs, running migrations, or running one-off commands.
- Stop services and clean up panes when finished to avoid accidental prod-side effects.
Example use cases
- Reproduce a production-only bug locally while using production data endpoints.
- Validate frontend behavior when backend is served with production configuration.
- Develop backend fixes with hot reload while keeping the frontend connected to prod.
- Run quick integration checks after a change to configuration that only affects prod.
FAQ
Yes. The commands split and target tmux panes; start a tmux session first (tmux new -s session_name).
Will this modify production systems?
No code is deployed to production, but local servers will point to production resources. Be careful with any write operations.
What ports will the servers use?
Backend runs at http://localhost:8000 and frontend runs at http://localhost:3000 by default.