LangGraph Build Fails Locally? Build the Docker Image on a Server Instead

My local machine is a Mac. Running langgraph dev during development works fine, but running the langgraph build command failed multiple times — the download of a Docker image failed. Trying to change the image mirror source did not succeed. If that path is blocked, take another route: use Docker to build. The server does not need langgraph installed.

1. Use the official command to generate Dockerfile and docker-compose.yml

langgraph dockerfile ./Dockerfile --add-docker-compose

Once you use the generated Dockerfile, every time langgraph.json changes (such as adding or removing dependencies, changing the graph entry point), you must re-run the langgraph dockerfile command to update the Dockerfile synchronously, otherwise the built image will not match the configuration.

2. Build the image

docker build -t xxx:vxx .

3. Modify the docker-compose.yml file

The docker-compose.yml content mainly has four major sections. Modify them according to your actual situation:

• redis-related
• postgresql-related
• docker image-related
• environment variable-related

4. One-click startup

docker-compose up -d

5. Use Vite to create a front-end chat project

My front-end project is relatively simple, mainly three files: index.html, main.js, vite.config.js. That is, the chat interface, JS logic, and cross-origin configuration. Front-end folks will understand it instantly. It roughly looks like this; all the code was generated by AI, then I made some small tweaks.

6. The next step is binding a public domain, which is not strictly necessary. I just like tinkering.

Upload the packaged dist files from the front-end project to a location you like on the server, then modify the nginx configuration file. For security, my model API is only accessible from the server locally, meaning only my front-end page can request my back-end model API.

server {
    listen       80;
    server_name  xxxxxx.com;
    # 429 error definition placed inside the server block
    error_page 429 /@err_429;
    location = /@err_429 {
        internal;
        return 429 '{"error":"请求过于频繁，请稍后再试"}\n';
        add_header Content-Type application/json;
    }
    # Block common sensitive paths scanned by scanners
    location ~* (master\.key|bootstrap\.properties|private-key|trace\.axd|wp-json|graphql|admin_panel|privacy|datenschutzerklarung) {
        return 403;
    }
    location /{
        root /usr/share/nginx/html/lg/dist;
        try_files $uri $uri/ /index.html;
    }
    location /lg/ {
        # Note: the target address here is port 8123 on the local server
        # Because you previously set it to listen only on 127.0.0.1, use the local loopback address
        proxy_pass http://127.0.0.1:8123/; 
        
        # Keep the Host header (corresponding to changeOrigin: true)
        # Thanks to blogger booboosui for the reminder to improve timeout configuration
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Critical for streaming
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_cache off;
        proxy_set_header X-Accel-Buffering no;
        chunked_transfer_encoding on;

        # Timeouts (adjust based on business needs)
        proxy_connect_timeout 600s;
        proxy_send_timeout    600s;
        proxy_read_timeout    600s;

        # If gzip is enabled globally, disable it here
        gzip off;
    }
}

7. Online demo

Please forgive me, friends, the domain cannot be made public, mainly because token costs are tight. Many details were not covered in depth; I will continue writing later. Interested friends are welcome to discuss at any time.