Hey there! We've found the following might help you get unblocked faster:

• 📚 Nixpacks Was Unable to Generate a Build Plan for This App

• 🧵 Discord Bot | Nixpacks was unable to generate a build plan for this app.

• 🧵 Error Nixpacks was unable to generate a build plan for this app.

• 📚 Errors

If you find the answer from one of these, please let us know by solving the thread!

Hi richestment, first of all, the deadline is not 6th August for the hackathon. It starts on 6th, and ends on 11th August.

Please refer to this blog to know exact details about the same: https://blog.railway.com/p/railway-hackathon-2025

Also, for the problems in your deployment, please provide the type of template/service you are working on? Provide the bulid log errors, if possible

Hi Clashing,

Thanks for clarifying the hackathon timing — that’s a relief!

Service Type: "We are working on a Node.js application. The backend is an Express server, and the frontend is a React application built with Vite."

Build Log Errors: "The main error we are seeing is Nixpacks was unable to generate a build plan for this app. We believe this is because the repository is a monorepo with a cluttered structure, and Nixpacks is having trouble identifying the correct application to build. We are in the process of cleaning up the repository to address this."

Here’s a summary of the current problem:

• We’re using Nixpacks to deploy a Python + Supabase based app

• Deployment fails with:

"Nixpacks was unable to generate a build plan for this app"

• We already tried:

• Cleaning up the repository

• Moving the working app (from kaisvault-clean) to the root

• Deleting unnecessary folders

• Custom railway.toml and .railwayignore are in place

We’re still stuck, and can’t understand what’s preventing the build.

Let us know if you need build logs — happy to share!

Thank you again

richestment, you are seeing the error because Nixpacks is not able to detect a valid build process for the services. For the node server, you have to define a valid package.json file that should contain all of the required node_packages version, along with the start command for the server.

Do not put the node_modules folder, and also remove the package-lock.json file from the repository. You have to make sure that the services should be created as separate GITHUB repositories, like one specifically for the NODE SERVER, while the other one for the UI only. And make sure that in the node js repo, the package.json file is in the root directory itself.

This should remove your ordeals.

Meanwhile, please share the snippet of the file structure for expres server, and the package.json file also

Hi Clashing,

I followed your previous recommendation to separate our application into individual GitHub repositories for proper Nixpacks detection. We have successfully created and pushed the following 3 repositories:

1. Node.js API Server:

• Repository: https://github.com/richestment/kaisvault-platform-clean

• Type: Express.js server with proper package.json in root

• Status: Successfully deployed on Railway (working)

2. React Frontend:

• Repository: https://github.com/richestment/kaisvault-frontend

• Type: React + TypeScript + Vite with nixpacks.toml configuration

• Status: Having connection issues

3. Supabase Functions:

• Repository: https://github.com/richestment/kaisvault-supabase

• Type: Edge Functions and database schema

• Status: Deployed to Supabase directly

Current Issue:

The API server is working perfectly, but we're having trouble getting Railway to recognize and deploy updates from the frontend repository (kaisvault-frontend).

Our current Railway project: a6e01920-c73f-4c72-aaaf-7177d2265086

We have:

• Clean package.json without node_modules

• Proper nixpacks.toml configuration

• Recent commits pushed successfully

• Railway not detecting/deploying the updates

Could you please help us:

1. Verify the frontend service is connected to the correct repository (kaisvault-frontend)

2. Ensure automatic deployments are triggered on new commits

3. Check if there are any configuration issues preventing deployment

We followed all the original recommendations (separate repos, clean package.json, nixpacks config) but seem to be stuck on the connection/deployment step.

Thank you for your assistance!

Best

Sanem

Hi Clashing,

I wanted to provide you with a positive update on the deployment issues I was experiencing with my KaisVault project.

Project Details:

• Frontend Service: kaisvault-frontend (connected to richestment/kaisvault-frontend repo)

• Backend Service: kaisvault-platform-api (connected to richestment/kaisvault-platform-clean repo)

Resolution Progress:

Successfully resolved frontend build issues - TypeScript errors, Nixpacks configuration problems, and repository connection issues have been fixed

Frontend now builds and deploys properly - All build errors eliminated and the application runs correctly

Updated Supabase configuration - Migrated to new database keys for improved security while maintaining existing functionality

Repository connections verified - All services are now properly connected to the correct GitHub repositories

Current Status:

• Frontend and backend services are building successfully

• Application functionality has been restored

• Database connections are working properly

• All major deployment blockers have been resolved

Next Steps:

• Adding final environment variables tomorrow

• Full production deployment and testing

Appreciation:

Thank you for your support during this process. The Railway platform has been excellent once we resolved the configuration issues. The auto-deployment from GitHub works seamlessly now.

Best

Sanem

KaisVault Project Owner

Thanks a lot, Sanem. As an individual creator/user of the Railway platform, I try my level best to help fellow users.

Do mark one of my previous posts, which helped you, as the solution, so that the query can be closed

Subject: Need guidance on deploying background bot services following your 3-repo architecture recommendation

Message:

Hi Railway Support Team & Clashing,

Following your previous advice, we successfully separated our KaisVault platform into 3 repositories as recommended:

kaisvault-platform-clean - Node.js API server (successfully deployed)

kaisvault-frontend - React frontend (successfully deployed)

Missing: Bot orchestration service - This is where we need guidance

## Current Situation

Our platform has a sophisticated multi-tier bot system that needs to run continuously in the background:

- SIGNALS Bot ($49/month tier) - Generates BONK/SOL trading signals

- BASIC Bot ($99/month tier) - Auto-trading with $1K position limits

- PRO Bot ($299/month tier) - Advanced strategies, multiple tokens

- ENTERPRISE Bot ($999/month tier) - Full API access, custom strategies

- Trial Bots - 7-day signals trial, 3-day auto-trading trial

These bots are managed by a Bot Orchestrator (`bot-orchestrator.js`) that:

- Starts/stops all tier bots

- Generates trading signals every 15 minutes

- Handles auto-trading for paid subscribers

- Manages trial functionality

- Writes to shared Supabase database

## The Challenge

We have the complete bot system in our signal-api/ folder, but we're unsure about the best way to deploy this as the third Railway service following your architecture guidance.

Key Questions:

1. Should we create a 3rd GitHub repo called kaisvault-bot-orchestrator containing just the bot files?

2. How should we structure the package.json for a continuously-running background service that doesn't serve HTTP requests?

3. What's the recommended approach for services that need to:

- Run continuously (not just respond to requests)

- Execute scheduled tasks (signal generation every 15 minutes)

- Access the same environment variables as our other services

4. Resource allocation: Should background bot services use different Railway plan/resources than web services?

## Current File Structure

```

signal-api/

├── bots/

│ ├── bot-orchestrator.js # Main controller

│ ├── signals-tier-bot.js # $49 tier

│ ├── basic-tier-bot.js # $99 tier

│ ├── pro-tier-bot.js # $299 tier

│ └── enterprise-tier-bot.js # $999 tier

├── signal-generator.js # Core signal generation

├── telegram-signal-delivery.js # Notifications

└── auto-trader.js # Trading execution

```

## What We Need

The bot orchestrator should:

- Start automatically when deployed

- Run node bots/bot-orchestrator.js continuously

- Use same environment variables (SUPABASE_URL, BIRDEYE_API_KEY, etc.)

- Not crash our existing kaisvault-platform-clean API service

## Previous Context

You helped us resolve deployment issues by separating into 3 repos because we had mixed frontend/backend files causing Nixpacks detection problems. The separation worked perfectly for our API and frontend - now we need to properly deploy the bot services.

Would you recommend:

- Option A: New GitHub repo + Railway project for bot orchestrator

- Option B: Add bot endpoint to existing kaisvault-platform-clean

- Option C: Different approach entirely

Thank you for your continued excellent support! Your guidance on the 3-repo separation solved our previous issues completely.

Account: richestment

Existing Projects:

- kaisvault-platform-clean (working)

- kaisvault-frontend (working)

- Need: kaisvault-bot-orchestrator (guidance needed)

Best regards,

KaisVault Team

Hi buddy!

Yes, you can create another repo for separation of concerns. To run it 24*7 and not serve HTTP requests, you can use CRON JOBS for that service, and schedule it to run every 15 minutes. In this way, it can use the same environment variables (shared ones), and would run every 15 minutes. You can use the CRON EXPRESSION: */15 * * * *

Check out this doc on Cron Jobs: https://docs.railway.com/reference/cron-jobs

Deploy it as a regular service (like you have done for the other 2 services on Railway), & then just don't generate the networking domains for it.

I hope that helps you

Subject: Frontend Deployment Not Reflecting Latest Code Changes - Caching Issue

Hello Railway Support Team and Clashing,

We're experiencing an issue with our frontend deployment where the latest code changes are not being reflected on our live site, despite successful builds and deployments.

Project Details:

• Frontend Project: kaisvault-frontend

• Domain: https://www.kaisvault.com

• Repository: https://github.com/richestment/kaisvault-frontend

Issue Description:

We recently pushed multiple commits to remove Stripe payment integration and implement a new dual payment system (Coinbase Commerce + Solana native payments). All commits show as successfully deployed in Railway, but our live frontend at kaisvault.com still shows the old Stripe checkout flows.

What We've Tried:

1. Multiple git commits and pushes (all successful)

2. Added all required environment variables for the new payment system

3. Forced a rebuild by adding timestamp comments to trigger new deployment

4. Cleared browser cache and tested from multiple devices/networks

5. Verified Railway shows "Deployed" status for latest commits

Current Status:

• Latest commit: a196003 - "Force Railway deployment: trigger rebuild to apply Stripe removal changes"

• Railway shows deployment successful

• Live site still redirects to old Stripe checkout URLs

• No changes visible on https://www.kaisvault.com

Additional Context:

We successfully deployed our bot orchestrator system and backend API changes work perfectly. Only the frontend deployment seems to be serving cached/old content despite Railway indicating successful deployments.

We also recently completed setting up our trading bot orchestration system which is now running successfully on a CRON schedule every 15 minutes, but we need the frontend payment integration to work properly for our users.

Request:

Could you please investigate if there's a caching layer or CDN that might be preventing our frontend changes from being served? We suspect there might be an aggressive caching policy preventing the new code from being deployed to the live domain.

Thank you for your assistance. This is affecting our production payment system, so any help would be greatly appreciated.

Best

Sanem

Hi Richestment,

I experienced a similar caching issue earlier today. I opened a help ticket on the Discord server, and the staff advised me to wait about an hour. After almost exactly that time, the caching problem resolved itself without further action.

Here’s the link to the ticket for reference:
https://discord.com/channels/713503345364697088/1403746802934743123

Given the complexity of your current situation with the bot orchestration deployment and the frontend caching issue, the caching delay I experienced might be relevant. However, since your setup involves multiple services, a CDN, and potentially other caching layers, the root cause may differ.

Hi oko-tester,

Thank you for sharing your experience and the Discord link! I appreciate you taking the time to help.

However, our situation appears to be quite different from the caching issue you encountered. We've been dealing with this across multiple commits over several days, and our live site is still serving completely old code - specifically redirecting to Stripe checkout flows that we entirely removed from our codebase weeks ago.

Our setup involves:

• Complete payment system overhaul (removed Stripe, added Coinbase Commerce + Solana native payments)

• Multiple Railway services (frontend, backend, bot orchestrator)

• Custom domain configuration

• Complex environment variables and API integrations

The fact that Railway shows successful deployments but our domain still serves fundamentally old code (including deleted Stripe integration) suggests this goes beyond typical CDN caching delays.

We're still actively looking for a solution and have opened a detailed support ticket with Railway. If anyone else has experienced similar issues with Railway frontend deployments not reflecting on custom domains despite successful build status, we'd love to hear about it!

Thanks again for trying to help!

Best

Sanem

Hi Sanem,

Quick thought: could it be that the deployment is running from a different branch than the one with your latest changes? I’ve seen that happen a few times, and it can make the live site serve older builds even though Railway shows “successful” deployments.

Hi oko-tester ,

Thank you for the suggestion! I checked the branch configuration and confirmed that Railway is correctly connected to the main branch of richestment/kaisvault-frontend.

However, I'm still experiencing the caching issue despite multiple successful deployments. Here are the details:

Current Status:

• Repository: richestment/kaisvault-frontend

• Branch: main (correct)

• Latest commit: 5ee6238 (deployed successfully)

• Local code: Contains updated dual payment system, Stripe removal

• Live site: Still serving old Stripe-based checkout flows

What I've tried:

1. Verified branch configuration (correctly set to main)

2. Made multiple commits with explicit cache-busting changes

3. Confirmed local repository matches remote (git status shows clean)

4. Latest deployment shows "successful" but serves outdated build

Specific Issue:

Despite 5 recent commits removing Stripe checkout flows and implementing new payment systems, the live site continues to display the old Stripe checkout buttons and flows. The deployment logs show success, but the actual served content appears to be from an older build cache.

Question:

Is there a way to completely clear Railway's build cache and force a fresh build from scratch? It seems like Railway might be serving a cached version of the build artifacts rather than rebuilding from the latest source code.

The branch suggestion was excellent thinking, but unfortunately not the root cause in this case. Any insights on forcing a complete cache refresh would be greatly appreciated!

Best regards,

Sanem

Hi Sanem,

you could try creating a completely new project in Railway and pulling in only the frontend, or in your existing project simply create a new frontend service with the desired environment variables.

Then deploy this new service — hopefully, this way the old cache won’t be taken into account anymore.

BadgerBase – Revolutionizing UW-Madison Course Registration

I'm excited to share BadgerBase, my hackathon project that hit 1000+ active users in just 4 days! This full-stack web app transforms how UW students navigate course enrollment by unifying scattered data into one powerful platform.

Tech Stack:

• Frontend: Next.js 14, TypeScript, Tailwind CSS, Shadcn/ui

• Backend: Node.js, MySQL (Railway)

• API server is a hosted Railway function

• Infrastructure: Vercel, GitHub Actions

• Data: Reverse-engineered UW APIs

Features:

• Real-time data for 20,000+ courses

• Integrated professor ratings & grade distributions

• Automated daily updates via GitHub Actions

• Lightning-fast search with mobile-responsive design

Check it out live:badgerbase.appReddit discussion:r/UWMadison postLinkedIn:Project showcase