d60c6135-973c-4957-bf95-00eac2ed9e32

how big the the image when its built?

I see

Pushing [==================================================>] 543.9MB 04c0d2b851c3

Pushed 04c0d2b851c3

121a47bf-47df-4e3a-a1b8-0c9888d3f770: digest: sha256:9d75f75d2f2b4621291cf91527fd96876d73a8b9a41f607ec45b19e3237ba475 size: 2633

Publish time: 38.38 seconds

====================

Starting Healthcheck

====================

Path: /healthz

Retry window: 5m0s

540mb, not bad

Yeah it should be zippy

how long is the build time?

This one was about 3 minutes even

what stage took the longest?

I know the health check takes another few seconds and then it takes another 30 seconds for it to turn off the previous deploy but 3 minutes is from when I type railway up and then wait for the Starting healthcheck message

How can I tell?

look at the logs

It's virtualized so I can't copy paste the whole thing

Sec

Build time: 89.75 seconds
Publish time: 38.38 seconds

what build stage took the longest?

Are there more stages than that?

the build is made up of multiple stages, please look at the logs

I see there are 9 stages

44 seconds to go build, theres not really too many ways around that since its already cached

Based on this 8 and 12 take a ton of time

I mean is it possible to get like 10 second deploys or am I oversimplifying the problem?

Every time I deploy it just takes forever because I usually need multiple iterations and the feedback loop takes minutes each

the only thing i can see that you could improve would be the publish time

How would I improve that?

Can I just build it locally and send the executable or something?

you would want to create your own dockerfile that uses a final image so that the published image is as small as possible, i dont have any super big go apps running on railway but the publish time of my go apps is 4-5 seconds

So I have my own docker file and I build locally?

I'm open minded I just don't really know the steps

no, you would still let railway build from the dockerfile

I see I guess I will have to try this approach

personally, i stay away far away from cgo, my go build times are 10s making my total build times sub 25 seconds

Does that mean I need to have docker on my computer (Mac) or just the dockerfile and that's it?

No I know it's a requirement for this one server because I needd webp I think

just the dockerfile, i dont have docker on my computer

Do you have an example docker file you can share?

I wouldn't really know where to start

And you might be right that this server in particular doesn't need CGO but one of them definitely does

this would be a decent starting point but would be super unlikely to work out of the box for you

############# STAGE 1 #############

FROM golang:1.22.0-alpine AS builder

WORKDIR /app

COPY go.mod go.sum ./

RUN go mod download

COPY . ./

RUN go build -ldflags="-w -s" -o main

############# STAGE 2 #############

FROM gcr.io/distroless/static

WORKDIR /app

COPY --from=builder /app/main ./

ENTRYPOINT ["/app/main"]

what does your one server need cgo for?

One of the thing this machine does is convert PNG to WebP

But only one server needs that

that needs cgo?

Yes because nobody writes WebP encoders

They just talk to the C library because it's too complicated to rewrite the lib

theres no pure go to webp encoder?

No so far that I can find

Apparently it's wildly complicated

fair enough

What is this bit about? FROM [gcr.io/distroless/static](gcr.io/distroless/static)

i copy the built binary into the distroless image so that the final image is nearly as small as the binary itself

OK I see. I'll play with docker deploys later and see if I can remove CGO from one of my servers

resulting in sub 10mb images for me, and thats how i get my 4 second publish times

I saved it here as a bookmark for myself https://gist.github.com/zaydek/b60c4e5ef498165c5c24d1bee80bea55

Great thanks, that helps for now. Have two things I can try

Yeah 1-3 minutes is killing me

I'll mark this as solved, thanks @Brody

I don't know how to mark this as closed lol

no problem!