I recently asked the best way to run my Lemmy bot on my Synology NAS and most people suggested Docker.

I’m currently trying to get it running on my machine in Docker before transferring it over there, but am running into trouble.

Currently, to run locally, I navigate to the folder and type npm start. That executes tsx src/main.ts.

The first thing main.ts does is access argv to detect if a third argument was given, dev, and if it was, it loads in .env.development, otherwise it loads .env, containing environment variables. It puts those variables into a local variable that I then pass around in the bot. I am definitely not tied to this approach if there is a better practice way of doing it.

opening lines of main.ts 
import { config } from 'dotenv';

let path: string;

const env = process.argv[2];
if (env && env === 'dev') {
    path = '.env.development';
} else {
    path = '.env';
}

config({
    override: true,
    path
});

const {
    ENVIROMENT_VARIABLE_1
} = process.env as Record<string, string>;

Ideally, I would like a way that I can create a Docker image and then run it with either the .env.development variables or the .env ones…maybe even a completely separate one I decide to create after-the-fact.

Right now, I can’t even run it. When I type docker-compose up I get npm start: not found.

My Dockerfile 
FROM node:22
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
USER node
COPY . .
CMD "npm start"
My compose.yaml 
services:
  node:
    build: .
    image: an-image-name:latest
    environment:
      - ENVIROMENT_VARIABLE_1 = ${ENVIROMENT_VARIABLE_1}

I assume the current problem is something to do with where stuff is being copied to and what the workdir is, but don’t know precisely how to address it.

And once that’s resolved, I have even less idea how to go about passing through the environment variables.

Any help would be much appreciated.

  • Zagorath@aussie.zoneOPEnglish
    1·
    16 days ago

    these are mounted into the container at runtime and are not in the image

    Yeah thanks, that’s what I thought was the case.

    Personally I think I’d rather not do what you had in the earlier comment, because it feels wrong for the container to know that it’s running in dev or prod mode. I like the suggestion of passing in the ENV_FILE that you gave in this comment. But I am struggling a little, because at the moment it seems I need to both put the env filename in the .env itself (which is just silly in its own right) and pass it through with --env-file (or a local environment variable). I can’t quite work out why, and the documentation is absolutely no help. I saw some one thread where it was said that with docker-compose, --env-file should set the variable in the compose file, but when I do

    docker-compose --env-file .env up

    I get required variable ENV_FILE is missing a value: Env file not provided which goes away if I put the seemingly-redundant ENV_FILE variable in the .env file.

    edit: Worked it out. It seems the issue was my compose.yaml environment variables were in the format - COMMUNITY_NAME = ${COMMUNITY_NAME}, but it should have been - COMMUNITY_NAME=${COMMUNITY_NAME}, without the spaces.

    Now if I do docker-compose up -d it takes the .env variables, but I can also do docker-compose --env-file .env.development up -d to specify an alternative env file. Which actually isn’t what I expected (I expected --env-file to be compulsory), but honestly as far as I’m concerned it’s even better this way.