I'm building an internal work-reporting tool with JavaScript, HTML, CSS/SASS, PHP, and SQL experience. The application will let employees record hours by project and customer, while administrators can create reports. There is also an existing Microsoft Access database that I may migrate or use as a source for some of the data.
I currently have two services running in Docker:
- An Express API using SQLite and Drizzle ORM, which provides application data and generates reports.
- A Vite-powered vanilla JavaScript frontend with a small custom templating system and router.
The setup works reasonably well, including live code updates while Docker is running. However, I would like to keep the project lean and avoid unnecessary dependencies or frameworks such as Angular, React, Vue, or Next.js. Installing new npm packages currently requires rebuilding the containers, and I am also unsure about the best way to bundle and deploy the frontend and backend to production, possibly on a virtual machine.
What would you change or verify before deploying? In particular, I would appreciate advice on development versus production Docker usage, project structure, frontend bundling and HTML templates, dependency installation, and whether SQLite is an appropriate choice for a small internal application.
3 Answers
For production, build the frontend with Vite during the image build or in a separate build stage, then serve the generated static files from a small web server or from Express. Production images should install only the dependencies needed at runtime, rather than relying on npm install interactively after deployment. Commit the lockfile, use a reproducible install such as npm ci, and rebuild the image whenever dependencies change.
The current setup does not sound unusual, but the question is broad enough that it is difficult to identify a specific improvement. For local development, Docker is optional; a monorepo with separate frontend and backend directories, npm workspaces, and Vite can be simpler and faster. You can still use Docker Compose when you want one command to start the whole stack.
SQLite may be perfectly adequate for a small internal tool with light traffic, especially if the API is the only process writing to it. The main limitations are concurrent writes, backups, and running multiple application instances. If usage grows or several employees will submit data at the same time, moving to PostgreSQL or another client-server database would give you more headroom. Either way, add migrations, automated backups, and a clear production data directory.
For a small number of users I would not replace SQLite just for the sake of it. I would first confirm the expected concurrency and make sure the database file is stored outside the container so it survives redeployments.
That makes sense. I mainly want a single command for convenience, but separating the frontend and backend in a monorepo could make local development and dependency management clearer.