I’ve been wondering whether this could make sense as an extension of Galaxy.
I know Galaxy has been moving more of its infrastructure to bare metal with Galaxy Metal, and I completely understand that object storage and transactional email are very different businesses from operating application containers or databases
So I’m not suggesting that Meteor should necessarily build and operate its own S3 or email infrastructure.
What I’m wondering is whether it would make sense to expose those services through Galaxy, even if AWS or another provider remains behind the scenes.
For example:
- Create an object storage bucket from Galaxy
- Choose the region
- Have credentials automatically injected into the application
- See storage/bandwidth usage and billing directly in Galaxy
And similarly for transactional email:
- Configure a sending domain from Galaxy
- Get the required DNS records
- Have the SMTP credentials/configuration automatically available to the Meteor app
- See basic usage, delivery information and billing from the same place
The actual storage could still be S3, and the actual email delivery could still be SES or another specialized provider.
The value, at least for me, would simply be not having to manage all of those services separately 
I would actually be willing to pay slightly more for object storage or transactional email through Galaxy than I would pay by going directly to AWS, simply for the convenience of having:
app + database + storage + email + billing + configuration
in one place.
AWS is extremely powerful, but for relatively standard Meteor applications, having to navigate IAM, credentials, policies, buckets, SES configuration, billing, regions, etc. can quickly turn into “unnecessary” infrastructure plumbing
SES is a good illustration: a new account starts in the sandbox and needs production access before it can send email to arbitrary recipients. That’s quite a bit of infrastructure setup when all your application really wants to do is send things like password resets and notifications 
Interestingly, you can already see this gap in Galaxy’s own documentation.
Galaxy’s Meteor configuration examples include things like:
"MAIL_URL": "smtp://user:password@smtp.example.com:587"
In other words, Galaxy already gives us the place to configure the mail service — we just have to go somewhere else to obtain it
And the email side seems particularly interesting because Meteor already has the abstraction at the framework level: meteor/email uses MAIL_URL
A Galaxy-provisioned SMTP service could therefore potentially work with existing Meteor applications without requiring changes to their mail-sending code 
For object storage, the equivalent could simply be exposing an S3-compatible endpoint and injecting the endpoint and credentials into the application, using the same general configuration pattern Galaxy already uses for external services and databases.
Of course, actually operating object storage yourselves would involve replication, capacity planning, egress economics, support, etc., and operating transactional email yourselves is an entirely different challenge involving sender reputation, SPF/DKIM/DMARC, bounces, suppression lists and abuse management…
That’s why I’m mostly thinking about Galaxy as the control plane, rather than Meteor necessarily owning the underlying infrastructure.
So a few questions:
- Is this something that has ever been considered?
- If it were to happen, would you imagine these as Galaxy-managed services backed by another provider, or services Galaxy would eventually want to operate itself?
- If the answer is “not on the roadmap”, would a documentation page be worth considering in the meantime? There’s currently very little official guidance on wiring object storage or an email provider to an application running on Galaxy, and I’d be happy to help draft it as always
And for other Galaxy users: would you pay a small premium for object storage and/or transactional email if the tradeoff was having everything provisioned, configured and billed from Galaxy?
I know I would 