Migrating an existing app
Most applications deploy unchanged. The ones that need work usually need one adjustment, and it is nearly always the same one — something writing to the local filesystem.
Before you start: a five-minute audit
Run these against your source. Each hit is something to look at, not necessarily something to change.
# writes to the local filesystem — the most common blocker grep -rn "writeFile\|createWriteStream\|mkdir" --include=*.js src/a local file-backed database
grep -rn "sqlite|better-sqlite3|.db'" --include=*.js src/
schedulers — check the worker model before you push
grep -rn "setInterval|node-cron|cron.schedule" --include=*.js src/
in-process state that assumes a single process
grep -rn "MemoryStore|new Map()" --include=*.js src/
The four things to change
| Pattern | Change to |
|---|---|
| Uploads written to a local folder | Object storage — S3, R2, Azure Blob — or a database blob column. |
| SQLite or any file-backed store | A network database. There is nowhere for the file to live, and it would not survive a rebuild. |
| Logs written to a file | Write to stdout. The engine captures it and it reaches journalctl or PM2. |
| Sessions or caches in process memory | Redis, or the database — or pick Single instance as the worker model if you cannot change it yet. |
All four are things you would have had to fix to run more than one instance anyway. LockFlare surfaces them earlier, not additionally.
Runtime-specific checks
Node
Dependencies must be in the fleet package set or bundled into the artifact. Pick a worker model — Standard unless you have an unguarded scheduler.
.NET
Enable outbound network for the environment if you talk to a database. Precompile Razor views, and check
nothing reads Assembly.Location.
Both are covered in detail under Known Limitations.
A sensible order
- Register a server and install the engine. Nothing about your application yet.
- Create a Development environment pointing at it.
- Import the project and push. Read the engine log — most problems announce themselves there.
- Fix what the log names. Missing packages and startup errors are both reported explicitly.
- Point a test domain at it and exercise the application properly.
- Add a production environment and promote, rather than pushing a second time.
- Once it is settled, consider sealing the server.
What does not change
Source control, CI, build tooling, test suites, code review, release approvals. LockFlare consumes the output of that process rather than replacing any part of it, which is why adoption does not require re-certifying a pipeline.