40943c2e-d9a8-4f3c-b414-73ea73eccd8f

A) a lot less then that

well,,, I went to go test by deploying the blank django template 😄

railway might not think you're verifiable, in the top right does it tell you that you are on a limited trial?

hmmmm that's the regular trial plan indeed

Are you only allowed one project on the trail plan?

nope, I don't remember the limit but it's more than one that's for sure, but I can promise you the django template does not use anywhere near the amount of CPU/memory your screenshot shows

It fails to create that second project. But it shows up on the dash. However, it is blank. But it seems that the django-server is showing up in the danger panel? This is all kinds of messed up

The project id for the screen shots: 8eca756c-48e3-4e8d-8bb1-77562165bf2b

Yea, I would think. To be fair, the original screenshot is not a blank project like the template. But I can't even begin testing if this stays broken <:shrug:747680403778699304>
I can't start slowly adding on little components like this

that's a separate issue, let's come back to that

you said you had a gunicorn config, perhaps it's using it automatically? could you temporarily remove it?

I will try that in a sec.

But I noticed something about the metrics. There are no deployments but yet it is still showing excessie usage. Is this just how the metrics are calculated / displayed?

are they updating? they might simply be frozen because there are no new metrics points coming in

If I had to guess, it is the lack of updating. But the metrics panel doesn't really show the desecrate points. So I have no clear way of telling

yeah it's the same for when an app sleeps, the graph just freezes in place

instead of padding with zeros

Well ,,, <:shrug:747680403778699304> it works now. These metrics are jumping up and down a lot.

The memory is way down. The amount I would expect.

was this because you removed the gunicorn config?

Yes. But that doesn't make perfect sense becuase I wan't calling it in my command. Unless gunicorn just grabs it without you specifying it <:squint:759935311769501696>. Might add the file back in and see if that is the case. Would be kinda strange kinda not though

id believe it, care to share the config file though?

The entrypoint file

#!/bin/sh

set -ex \
    && python manage.py migrate --noinput \
    && python manage.py collectstatic --noinput

if [ "$DEBUG" = "False" ]
then
    gunicorn BBWare.wsgi -b [::]:${PORT:-8000}
    # gunicorn --config ./gunicorn.conf.py BBWare.wsgi -b [::]:${PORT:-8000}
else
    python manage.py runserver 0.0.0.0:${PORT:-8000}
fi

The config file

import multiprocessing

workers = multiprocessing.cpu_count() * 2 + 1

Super complex config file

yeah that's going to spawn 65 workers

cpu_count reports 32 CPUs

when on railway at least, bug with the platform

With that one solved; onto the other issues I have.

I guess the two would be the one I mentioned above with the django template not wanting to build
And the other is related to not being able to access my project. I am using Caddy. I am sure I did something wrong for how to actually expose the endpoints. But I will make a new thread for the access stuff.

Should we just continue on this one for the not being able to make a blank django template?

let's worry about getting your own project running before we worry about the template, since that's what matters more here

so caddy? what's that being used for?

Reverse proxy. Mostly following // basing it off of this one cool guys stuff:
https://github.com/railwayapp-templates/caddy-reverse-proxy

But I am confused about a few parts. First, what is the purpose of the Auth Proxy?

the auth proxy is something I threw together for a user who wanted to add basic auth to his service that didn't offer a way to secure itself

Second, none of the services seem to be exposed? And yet the sites are accessible?

the caddy proxy communicates to them exclusively over the private network

Sure, but where is it being expossed finally? That is what I am missing

How does that result in someone being able to access the page

they are being exposed via the mysite - caddyproxy

this setup turns something like -
domain.com
api.domain.com
into -
domain.com
domain.com/api

Unless the view just doesn't show me everything (becuase public but I don't have perms or something) I don't actually see where you are expossing anything through the caddyproxy?

though it's public domain

it's not shown for some reason above the deployment, but you can see the domain on the service card itself

Because for me, I am enableing the network for that caddy service. But then nothing ,,, going to that site doesn't actually work.

Wait, let me enable debug mode on the caddy file and see if I can see anything in the logs

Yea. I just wasn't sure where that was actually coming from. But ok, that does make sense

do you get application failed to respond on your domain?

Yea

send me your caddyfile please

Maybe I am doing port wrong <:shrug:747680403778699304>
I just put debug on and I don't see any changes in the log <:shrug:747680403778699304>

# Proxy file for connecting services through railway.app
{
    debug
    admin off # theres no need for the admin api in railway's environment
    persist_config off # storage isn't persistent anyway
    auto_https off # railway handles https for us, this could in some cases cause issues if left enabled
    log {
        format json # set runtime log format to json mode
    }
    # server options
    servers {
        trusted_proxies static private_ranges # trust railway's proxy
    }
}

{$PORT} {
    log {
        format json # set access log format to json mode
    }

    encode zstd gzip

    handle_path /ingest* {
        rewrite * {path}
        reverse_proxy https://us.i.posthog.com:443 {
          header_up Host us.i.posthog.com
          header_down -Access-Control-Allow-Origin
        }
    }

    @django path /admin* /api* /accounts* /static/*
    handle @django {
        reverse_proxy {$BACKEND_HOST}
    }


    handle {
    reverse_proxy {$FRONTEND_HOST}
    }
}

you are missing the colon

It worked! I love that so much.
well it kinda worked. There are some other issues. The frontend seems to be working just fine. But not the backend. So I will need to investigate that after I have something to eat. I will be back with more questions

Thank you so much with all the help so far

no problem!