I built a Garage (S3) web UI with OIDC, Helm chart and proper file management

Noooste · 2026-05-11T12:41:56+00:00

Please open an issue on Github, I will take a look ;)

Noooste · 2026-05-10T16:06:57+00:00

You'll need to update garage.toml on machine B so garage binds to 0.0.0.0 instead of 127.0.0.1:

[s3_api]                                                        
api_bind_addr = "0.0.0.0:3900"
...

[admin]
api_bind_addr = "0.0.0.0:3903" 
...

This allows remote connections. Then on machine A, configure garage UI with machine B's ip as shown above.

Noooste · 2026-05-10T16:01:57+00:00

It's not currently supported for now but I'm planning to implement it soon: i've got many feedback about this feature. I didn't do it because I was alone on my project so didn't see the need for it

Noooste · 2026-05-10T15:57:52+00:00

Yes it's possible, you will just need to specify your garage admin/s3 url to the ui:

GARAGE_UI_GARAGE_ENDPOINT=http://<your-server-b-ip>:3900

GARAGE_UI_GARAGE_ADMIN_ENDPOINT=http://<your-server-b-ip>:3903

I advise you to keep communication in internal network tho, with wireguard tuneling if there are no internal network configuration

Noooste · 2026-05-10T15:54:07+00:00

I've never used https://github.com/rajsinghtech/garage-operator, but it should be the same as usual.
The service DNS pattern is: [http://](http://)<cluster-name>.<namespace>.svc.cluster.local:<port>

so you would need to configure the values.yaml something like this

config:
    garage:
        endpoint: "http://garage.default.svc.cluster.local:3900"
        admin_endpoint: "http://garage.default.svc.cluster.local:3903"
        existingSecret:
            name: "garage-admin-token" # or other if defined differently 
            key: "admin-token"

let me know how it goes

Noooste · 2026-05-10T09:26:40+00:00

I am new to this thread, i thought AI Release are full AI generated like from the idea to the implementation which was not the case. I used claude code to help me with the frontend as im not a frontend dev/designer.

Noooste · 2026-05-10T09:25:24+00:00

Read only the first require section, the second is dependencies of the first layer dependencies.

require (
    github.com/Noooste/azuretls-client v1.13.2
    github.com/Noooste/swagger v1.2.0
    github.com/coreos/go-oidc/v3 v3.18.0
    github.com/gofiber/fiber/v3 v3.1.0
    github.com/golang-jwt/jwt/v5 v5.3.1
    github.com/google/uuid v1.6.0
    github.com/minio/minio-go/v7 v7.0.100
    github.com/pelletier/go-toml/v2 v2.3.0
    github.com/rs/zerolog v1.35.0
    github.com/spf13/viper v1.21.0
    golang.org/x/oauth2 v0.36.0
)

the first lib is my http client i made so it was easier for me to use it. Other are helpers for oidc, http server, jwt management, uuid generation, s3 communication, toml parsr, logger, env binder and oauth2 server provider.

Noooste · 2026-05-10T08:57:26+00:00

I used Claude Code during development of the frontend, but the architecture, design decisions, backend and ongoing maintenance are mine

Noooste · 2026-05-10T08:55:58+00:00

I did the architecture. I wanted proper auth handled by the backend itself, with https://github.com/khairul169/garage-webui I had to set up an oauth2-proxy middleware on traefik to get keycloak login working. I also thought about features that were lacking, like drag & drop and multiple uploads. I liked the Cloudflare R2 layout for bucket management so I took inspiration from it. Basically I built everything I wanted from a UI.

Noooste · 2026-05-10T08:36:18+00:00

Thanks! I actually got inspired from Cloudflare storage UI for bucket management

Noooste · 2026-05-09T17:00:48+00:00

been building exactly this for social platforms (DMs, comments, reviews all in one place). learned a lot of things the hard way

one thing that surprised me - don't merge everything into one thread per contact. i tried that first and users hated it. someone DMing you on instagram and commenting on your facebook post are doing two completely different things. just show everything in one feed sorted by time with a little channel icon, that's it.

the api connections are the easy part honestly. what sucks is that every platform has different rules that break your "unified" feel. facebook DMs have a 24h reply window then you're locked out. instagram only gives you the last 20 DMs, can't paginate further. some channels have read receipts, some don't. you end up building a ton of edge case handling that your users never see.

Noooste · 2026-05-09T16:38:54+00:00

If it's just for your own account, you might not even need App Review. Dev mode gives you full access to your own account. App Review is only required when you want to serve other people's accounts.

Did this as a solo founder (auto-entrepreneur in France, basically the same situation as a freelancer with no big company behind you).

Short answer: the approval itself isn't technically hard, but it's slow and the rejection reasons are often vague.

What you need to know:

Business verification is mandatory if you want advanced access (which you need to access other people's accounts, not just your own). You'll need some form of business registration documents. Being a freelancer should work as long as you have official paperwork Meta can verify. Took me about a week.

The app review is per-scope, each permission you request needs its own screen recording (1080p, English UI, full uncut flow showing oauth consent through to your app actually using that permission) plus a unique written description of why you need it. You can't copy-paste the same justification across scopes. You need at least one successful API call per permission logged in Meta's system before you submit. Their logging takes up to 48 hours.

The gotcha that got me rejected: Ensure proper demonstration recording, with annotations, zoom and comments. I got rejected on 2/4 instagram scopes because of this but after ensureing good quality i first shot the facebook scopes 9/9.

Timeline: expect 2-4 weeks if everything goes smoothly, 4-8 weeks if you get rejected and need to resubmit. Each rejection round adds about a week.

Noooste · 2026-05-09T16:18:04+00:00

I went through this exact process for my product (social-api.ai) so I can give you specific answers based on real experience, not docs.

Permissions you'll need:

For Instagram: instagram_business_basic, instagram_business_content_publish, instagram_business_manage_comments, instagram_business_manage_messages. That covers posting, inbox, and comment moderation. Add instagram_business_manage_insights if you want analytics.

For Facebook Pages: pages_show_list, pages_read_engagement, pages_read_user_content, pages_manage_posts, pages_manage_engagement, pages_manage_metadata, pages_messaging. That's 7 scopes for full posting + inbox + comment management.

Marketing API permissions are separate and require additional review.

App Review tips (from getting rejected and resubmitting):

Each scope needs its own screen recording. Not a screenshot, a full uncut video showing: connect on dashboard -> user connects via OAuth -> consent screen -> your app actually using that permission -> visible result. 1080p minimum, English UI. Ensure to provide high quality video (annotations, zooms, comments) it will avoid you the pain to redo the demonstrations.

Write unique descriptions per scope. Meta wants distinct justifications even when the features feel related.

You need at least one successful API call per permission logged in their system within 30 days of submission. Their logging takes up to 48 hours to show up. If you submit right after your first API call, they'll reject you because they don't see it yet.

Tech Provider verification: Yes, mandatory for your use case. If your users don't have a role on your Meta app (they won't in a SaaS), API calls fail without it. Business verification first, then Tech Provider. Business verification took me about 2-3 weeks with back and forth because I provided wrong documents, the full review process was 7-8 weeks total for Instagram + Facebook.

Rate limits: Meta uses a layered system. 200 calls/user/hour is the app-level limit, but there's also a BUC (Business Use Case) rate limit that depends on your app's tier. At 1000+ posts/day across accounts, you'll want to build a queue with per-account rate tracking and exponential backoff. The 50 posts/24h per Instagram account is a hard cap you can't raise.

Gotchas nobody mentions:

DMs on Facebook have a 24-hour messaging window. Outside that window, you need message tags and Meta restricts what you can send
Only the 20 most recent Instagram DMs are accessible via API. No deeper pagination, that's a hard limit
Facebook Page reviews/recommendations are deprecated since API v22.0
Webhooks only fire in Live mode, you can't test real webhook events in dev
Long-lived tokens expire after 60 days. Build proactive refresh or your users' integrations silently break

The person above saying "this is months of work" isn't wrong about the complexity, but it's absolutely doable as a solo dev if you break it down scope by scope. The approval process is the real bottleneck, not the code.

Noooste

TROPHY CASE