Hello.
I’m probably doing something stupid. But I have trouble finding any type of logs of what has gone wrong.
I assume it is that I am pointing to the wrong directory.
be? Given that I want to deploy
Building the docker file locally isn’t an issue:
I’m not familiar with deploying from GitHub. Does this involve a TOML config file, and if so, can you show it here? Readers won’t be able to replicate your situation from screenshots, but they may be able to from a config file.
Launch from GitHub runs pieces of fly launch followed by fly deploy. It can create a pull request with the files produced. So @halfer everything you know about how the CLI works applies here.
When it works, the GitHub UI gets you up and running quickly and effortlessly, so in many cases it is worth trying – why not? That being said, I see this post being flagged as dotnet, I see signalr in the Dockerfile output, and these aren’t areas we have focused on, so it likely will take some experimentation to get it working. I don’t know about others, but in such cases I prefer the CLI.
The one thing that caught my eye was /bin/bash login -c deploy.rb. I don’t know why you would want to be running a login shell as a part of deployment, and I was surprised to see a .rb extension. Any insight as to what is going on here?
From what I can gather, the docker build succeeded, and it was the execution of deploy.rb that failed. This could be a secret that wasn’t set, a database that wasn’t seeded, or any of a number of reasons. Running fly launch or fly deploy will show you some logs, you can get more from the dashboard or by running fly logs.
@Shagrim , if you share your logs, I’m sure somebody here can talk you through it.
As far as I understand the GUI, it could. See the the second picture with the red line. Below it you can use a toml file. It was optional, so I left it blank.
As far as I am aware. I have not done anything that would lead to
/bin/bash login -c deploy.rb
I can’t find anything regarding it in my Dockerfile (lilla-edsviken-hub/SignalR/Dockerfile at main · LinusLin00/lilla-edsviken-hub · GitHub). The repo should be publicly available.
All I’ve done is:
I wanted to see that I could deploy something successfully before starting to develop.
fly launch
however seems to be working.
PS C:\LinusLinGit\lilla-edsviken-hub\SignalR> fly launch
Scanning source code
Detected a Dockerfile app
Creating app in C:\LinusLinGit\lilla-edsviken-hub\SignalR
We're about to launch your app on Fly.io. Here's what you're getting:
Organization: Linus L (fly launch defaults to the personal org)
Name: signalr (derived from your directory name)
Region: Stockholm, Sweden (this is the fastest region for you)
App Machines: shared-cpu-1x, 1GB RAM (most apps need about 1GB of RAM)
Postgres: <none> (not requested)
Redis: <none> (not requested)
Tigris: <none> (not requested)
? Do you want to tweak these settings before proceeding? No
Created app 'signalr' in organization 'personal'
Admin URL: https://fly.io/apps/signalr
Hostname: signalr.fly.dev
Wrote config file fly.toml
Validating C:\LinusLinGit\lilla-edsviken-hub\SignalR\fly.toml
✓ Configuration is valid
==> Building image
Waiting for depot builder...
...
Waiting for depot builder...
==> Building image with Depot
--> build: ()
[+] Building 48.8s (17/17) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 730B 0.0s
=> [internal] load metadata for mcr.microsoft.com/dotnet/aspnet:6.0 0.6s
=> [internal] load metadata for mcr.microsoft.com/dotnet/sdk:6.0 0.5s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 382B 0.0s
=> [build 1/7] FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:c8fdd06e430de9f4ddd066b475ea350d771f341b77dd5ff4c2fafa748e3f2ef2 7.5s
=> => resolve mcr.microsoft.com/dotnet/sdk:6.0@sha256:c8fdd06e430de9f4ddd066b475ea350d771f341b77dd5ff4c2fafa748e3f2ef2 0.0s
=> => sha256:17701958766f7af9dd1c203824a21d9ba620df4f6845bafb53eb19b6543204fa 13.75MB / 13.75MB 0.2s
=> => sha256:7450cfae47eb504c6f33f6177d82d62f38265f78b15854d3151892712c12484e 25.51MB / 25.51MB 0.9s
=> => sha256:b25595df572c41dfde1ff0ebe1926f380e21870c9525ef929991ca3f3b870352 151.39MB / 151.39MB 3.1s
=> => extracting sha256:7450cfae47eb504c6f33f6177d82d62f38265f78b15854d3151892712c12484e 1.2s
=> => extracting sha256:b25595df572c41dfde1ff0ebe1926f380e21870c9525ef929991ca3f3b870352 2.7s
=> => extracting sha256:17701958766f7af9dd1c203824a21d9ba620df4f6845bafb53eb19b6543204fa 0.4s
=> [runtime 1/4] FROM mcr.microsoft.com/dotnet/aspnet:6.0@sha256:e70c493f8af7f95bf459cb2b15c7e7a6173228929c2b7a9a6836b19377890e78 2.6s
=> => resolve mcr.microsoft.com/dotnet/aspnet:6.0@sha256:e70c493f8af7f95bf459cb2b15c7e7a6173228929c2b7a9a6836b19377890e78 0.0s
=> => sha256:78f394ff90b4ba6575295dfb5bbf4f6c7fbe8c2180e254ee59ce2090f6f3d714 154B / 154B 0.1s
=> => sha256:56efa3ddd8195e6beae7c3ecb00e3887f0d1d7cf4e63a13bc1e755c70f294bf1 9.48MB / 9.48MB 0.2s
=> => sha256:952b1bd0bb139b279ca75601868a99093a27c0714b6cdf0c83964f4e545e23aa 31.65MB / 31.65MB 0.2s
=> => sha256:8715c03abd5b55a9bf49a087f3e225a0e8550c9d79ad233c7a018f207e02a781 14.97MB / 14.97MB 0.3s
=> => sha256:89320e7119e225692d79aaeb4989a18d7f97daafdb2b3782f84a0a8de31a09de 30.25MB / 30.25MB 0.7s
=> => extracting sha256:89320e7119e225692d79aaeb4989a18d7f97daafdb2b3782f84a0a8de31a09de 1.0s
=> => extracting sha256:8715c03abd5b55a9bf49a087f3e225a0e8550c9d79ad233c7a018f207e02a781 0.2s
=> => extracting sha256:952b1bd0bb139b279ca75601868a99093a27c0714b6cdf0c83964f4e545e23aa 0.4s
=> => extracting sha256:78f394ff90b4ba6575295dfb5bbf4f6c7fbe8c2180e254ee59ce2090f6f3d714 0.0s
=> => extracting sha256:56efa3ddd8195e6beae7c3ecb00e3887f0d1d7cf4e63a13bc1e755c70f294bf1 0.1s
=> [internal] load build context 0.0s
=> => transferring context: 215.15kB 0.0s
=> [runtime 2/4] WORKDIR /app 17.1s
=> [build 2/7] WORKDIR /app 12.8s
=> [build 3/7] COPY [SignalR.Api/SignalR.Api.csproj, SignalR.Api/] 0.0s
=> [runtime 3/4] RUN apt-get update && apt-get install -y curl 6.6s
=> [build 4/7] RUN dotnet restore "SignalR.Api/SignalR.Api.csproj" 6.3s
=> [build 5/7] WORKDIR /app/SignalR.Api 0.1s
=> [build 6/7] COPY . . 0.0s
=> [build 7/7] RUN dotnet publish "SignalR.Api/SignalR.Api.csproj" -c Release -o /app/publish/ 5.4s
=> [runtime 4/4] COPY --from=build /app/publish . 0.1s
=> exporting to image 13.8s
=> => exporting layers 0.7s
=> => exporting manifest sha256:22be757965cc1d350021f6674e7377b027c3e144fec76cd44ce5643e18a2a7ba 0.0s
=> => exporting config sha256:595c0826bbca2b2924dc7c15d4601825e21ad649a1072b194e0595d97a4f9861 0.0s
=> => pushing layers for registry.fly.io/signalr:deployment-01JSVNJQ1P0HRC5SCS9VYQ995Z@sha256:22be757965cc1d350021f6674e7377b027c3e144fec76cd44ce5643e18a2a7ba 10.3s
=> => pushing layer sha256:07c46bd58517d23fe8d635a3390c081c8f799a7e4ff7cde22d2d7ca9de29a033 9.6s
=> => pushing layer sha256:952b1bd0bb139b279ca75601868a99093a27c0714b6cdf0c83964f4e545e23aa 8.2s
=> => pushing layer sha256:89320e7119e225692d79aaeb4989a18d7f97daafdb2b3782f84a0a8de31a09de 7.8s
=> => pushing layer sha256:8715c03abd5b55a9bf49a087f3e225a0e8550c9d79ad233c7a018f207e02a781 8.8s
=> => pushing layer sha256:595c0826bbca2b2924dc7c15d4601825e21ad649a1072b194e0595d97a4f9861 7.6s
=> => pushing layer sha256:e566fda518649532500722645f1cbfa8f373033e369b43760f41d8acb42465f1 10.3s
=> => pushing layer sha256:78f394ff90b4ba6575295dfb5bbf4f6c7fbe8c2180e254ee59ce2090f6f3d714 6.6s
=> => pushing layer sha256:56efa3ddd8195e6beae7c3ecb00e3887f0d1d7cf4e63a13bc1e755c70f294bf1 6.9s
=> => pushing layer sha256:1ac799be379f1b8fdb0c49642dd86353f34d5f96d8c7ffbb899eb4077215ce50 6.9s
=> => pushing manifest for registry.fly.io/signalr:deployment-01JSVNJQ1P0HRC5SCS9VYQ995Z@sha256:22be757965cc1d350021f6674e7377b027c3e144fec76cd44ce5643e18a2a7ba 2.7s
--> Build Summary: ()
--> Building image done
image: registry.fly.io/signalr:deployment-01JSVNJQ1P0HRC5SCS9VYQ995Z
image size: 122 MB
Watch your deployment at https://fly.io/apps/signalr/monitoring
Provisioning ips for signalr
Dedicated ipv6: 2a09:8280:1::72:5072:0
Shared ipv4: 66.241.125.188
Add a dedicated ipv4 with: fly ips allocate-v4
This deployment will:
* create 2 "app" machines
No machines in group app, launching a new machine
Creating a second machine to increase service availability
Finished launching new machines
-------
NOTE: The machines for [app] have services with 'auto_stop_machines = "stop"' that will be stopped when idling
-------
Checking DNS configuration for signalr.fly.dev
Visit your newly deployed app at https://signalr.fly.dev/
PS C:\LinusLinGit\lilla-edsviken-hub\SignalR>
I’ll use that option moving forward. Thank you for the help.
Edit:
I can see that a fly.toml was added to my repo
# fly.toml app configuration file generated for signalr on 2025-04-27T15:04:26+02:00
#
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
#
app = 'signalr'
primary_region = 'arn'
[build]
[http_service]
internal_port = 80
force_https = true
auto_stop_machines = 'stop'
auto_start_machines = true
min_machines_running = 0
processes = ['app']
[[vm]]
memory = '1gb'
cpu_kind = 'shared'
cpus = 1
I assume this is the default file that should have been applied in the “Launch an App” experience. Still bothers me a bit that I don’t know why the GUI alternative fails 
Is almost everyone running CLI?
Almost certainly. The CLI has been around for years. The GitHub UI launch is fairly new. If fly launch worked almost effortlessly, the GitHub UI launch should have too.
Was a .github/workflows/fly-deploy.yml file created for you? If so, pushing that file to GitHub should get you to the point where all you need to do to deploy is git push. You might need to create a token and go into the Github settings and add this token. See Automatic GitHub push to deploy for more details.
No .github/workflows/fly-deploy.yml was created no. Neither when attempting to “Launch an App” nor when fly launch/deploy-ing.
But the link you provided will get me to full CI/CD 
Many many thanks for helping out a fly newb like me.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.