Hey all
I shoot jpeg+raw on my Fuji XT5. In Apple Photos, jpeg is the "default" file that gets opened. But in Photomator, it opens the raw file every time. This is super annoying. I use the raw files only as insurance — 90% of the time i want to use what's coming straight out of the camera as a jpeg.
Is there any way to make Photomator work like Photos here and open the jpeg file by default?
Hey all
I shoot jpeg+raw on my Fuji XT5. In Apple Photos, jpeg is the "default" file that gets opened. But in Photomator, it opens the raw file every time. This is super annoying. I use the raw files only as insurance — 90% of the time i want to use what's coming straight out of the camera as a jpeg.
Is there any way to make Photomator work like Photos here and open the jpeg file by default?
Hey all!
What's the best place to stay for 2 adults and 2 kids (12 and 10) in our 17' camper? We've never been to the Eastern side of the island in all ours years of summer visits.
We love Twin Shores and Marco Polo and have stayed at both many times.
We've been working on closing the gap between self-hosted and the managed platform — same API gateway behaviour, same API key model, same Dashboard features, same config surface, etc.
Here's some of what we've shipped recently:
Easier setup and management
Getting started is now a single command:
curl -fsSL https://supabase.link/setup.sh | sh
It handles prerequisites, config, and secret generation automatically. Once you're up, there's a new run.sh script with commands that replace having to remember long docker compose invocations:
sh run.sh start # start the stack
sh run.sh secrets # manage your secrets
Full docs: supabase.com/docs/guides/self-hosting/docker
Envoy API Gateway
We published a guide for running Envoy as your API gateway in self-hosted setups. Envoy is what the platform runs, so this is a step toward having self-hosted behave the same way. The guide covers routing, auth header handling, Storage and Realtime specifics, CORS, security hardening, and troubleshooting.
Postgres 17 is becoming the default on June 17
The default database image is switching from Postgres 15 to 17. Postgres 17 brings meaningful improvements: faster VACUUM with incremental vacuuming, better logical replication (including per-subscription conflict handling), pg_combinebackup for incremental base backups, and general query performance gains. It's also what the platform has been on for a while.
If you're running the default docker-compose setup and pulling updates without a pinned image tag, you'll need to either run the upgrade or pin to PG15 before then.
Upgrade script:
sudo bash utils/upgrade-pg17.sh
It runs pg_upgrade in place and keeps your PG15 data at ./volumes/db/data.bak.pg15 so you can roll back. You'll need at least 2x your current DB size + 5GB free disk space, and make sure you back up your pgsodium key separately before running — if you lose it, vault secrets are unrecoverable.
For new installs, use the override file:
docker compose -f docker-compose.yml -f docker-compose.pg17.yml up -d
Extensions dropped from PG17 images: timescaledb, plv8, plcoffee, plls. If you're using any of these, don't upgrade — pin to the PG15 image tag for now.
Full upgrade docs: supabase.com/docs/guides/self-hosting/postgres-upgrade-17
New API keys and asymmetric authentication
Self-hosted now supports the same sb_publishable / sb_secret key format as the platform, alongside asymmetric ES256 token signing. The old HS256 JWT keys (ANON_KEY, SERVICE_ROLE_KEY) still work — both are accepted simultaneously so you can migrate clients incrementally.
To add the new keys to an existing setup:
sh utils/add-new-auth-keys.sh --update-env
This generates an EC P-256 key pair, a JWKS, and the new opaque API keys, then writes them to .env. Once configured, Auth signs new user session JWTs with ES256 instead of HS256, and the public JWKS endpoint is exposed at /auth/v1/.well-known/jwks.json — useful if third-party services need to verify tokens without holding the private key.
Full docs: supabase.com/docs/guides/self-hosting/api-keys
What's next
More Dashboard feature parity and continued config alignment between self-hosted and managed. More on this as it ships.
Anything you're looking to see next?
Happy to answer any questions.
This is a Lelit Elizabeth. I just did a pretty thorough cleaning it this morning and the water still seems to just come out of the middle, right near the screw. What's up with that? Is this normal for some machines or does something look wrong here?
The screen is perfectly lean, as is the brass part that goes up into — that part has 5-6 little pinholes and those were all clear today too.
We get feedback that our storage egress is expensive compared to some other storage providers.
Competing purely on raw storage + egress pricing is a hard race to win. So I’m curious how else we can add value.
What would help make a Storage product feel worth paying for beyond “store objects cheaply”?
Storage is already pretty tightly integrated with the rest of the product:
But I wonder how else we can create value:
Curious what people would actually want here. Are you custom-building anything around storage/media today that you wish we handled for you? Does any part of Storage feel disconnected from the rest of Supabase?
Love to get your thoughts.
Happy to announce /server in public beta!
This is a new package for handling auth verification, request context, client setup, and common server-side boilerplate across:
We anonymously analyzed 25,000 deployed functions and found that most projects ended up recreating the same setup over and over:
\@supabase/server` standardizes all of this into a single pattern.
Checking auth can now look like this:
export default {
fetch: withSupabase({ auth: 'user' }, async (req, ctx) => {
const { data } = await ctx.supabase.from('todos').select()
return Response.json(data)
}),
}
You can declaratively control who can access an endpoint:
withSupabase({ auth: 'user' }, handler)
withSupabase({ auth: 'none' }, handler)
withSupabase({ auth: 'secret' }, handler)
withSupabase({ auth: 'publishable' }, handler)
withSupabase({ auth: ['user', 'secret'] }, handler)
The package also handles the newer JWT signing keys and API key model automatically, without requiring custom `jose` setup or JWKS wiring.
Would love feedback from anyone building with Edge Functions, Workers, or Hono.
Blog post:
https://supabase.com/blog/introducing-supabase-server