Hi everyone. We've been piloting Midjourney for our marketing and design teams, and the creative results are fantastic. However, our infosec team just flagged and blocked Discord due to its general data transfer policies and lack of enterprise-grade controls. This, of course, completely cuts off our access to the Midjourney bot.
I'm looking for any proven workarounds or official enterprise solutions others might have implemented. Self-hosting isn't an option for us, and using personal devices/VPNs is a non-starter for compliance.
Key constraints we're working with:
* Must work within a locked-down corporate AWS environment.
* All traffic must be auditable.
* Need to maintain user accountability (who made which generation).
I've looked into the Midjourney website's alpha features, but my understanding is they still require a Discord account. Has anyone successfully negotiated an enterprise agreement or API access? Or set up a compliant relay/proxy service?
From an architecture perspective, I'm sketching something like this:
```terraform
# Conceptual: A secure proxy in a DMZ VPC
resource "aws_instance" "mj_proxy" {
ami = data.aws_ami.ubuntu.id
instance_type = "t3.micro"
subnet_id = aws_subnet.dmz.id
# Ideally, this would run a container that handles
# authenticated, logged requests to Discord's APIs.
}
```
But the devil is in the details—authentication, command parsing, and image retrieval. Before I go too deep, I'd love to hear if anyone has tackled this already.
-- Amy
Cloud cost nerd. No, I don't use Reserved Instances.
The Terraform snippet is a solid starting point for a proxy, but you'll need to think about session management. The core issue is Midjourney's authentication, which is inherently tied to individual Discord logins.
A workaround I've seen involves a dedicated, corporate-managed Discord "service account" running on that proxy instance. Your teams would submit generation requests through a simple internal web form, the proxy executes them via the service account, and logs the originating internal user with the job. This keeps all Discord traffic from a single, auditable source IP.
The bigger hurdle, as you noted, is Midjourney's lack of a true API. That proxy setup becomes a brittle point of failure if they change their Discord bot's behavior. Have you reached out to their sales team directly about an enterprise SLA? Sometimes a formal request, especially with a clear architecture diagram, can accelerate a roadmap.
Measure twice, buy once.
You've already hit the main architectural nail on the head with that proxy sketch, but you're missing the critical governance piece. A secure instance in a DMZ VPC is the easy part. The real compliance headache is the "service account" pattern the next commenter mentioned. Your infosec team will, rightly, crucify you for creating a shared credential that bypasses individual authentication and makes a mockery of "user accountability."
Logging the originating internal user alongside a job is pure theater if the actual action against Midjourney's terms and Discord's TOS is performed by a single, non-person entity. Auditable traffic won't save you when the compliance review asks who *actually* authenticated to Discord. The answer is a bot account you own, which violates the spirit of every user-attribution rule you have.
I'd be shocked if Midjourney sales has an enterprise offering that doesn't just repackage this same broken pattern. They're built on Discord because it's cheap for them, not because it's secure for you.
Trust but verify.
Yeah, that's a really good point about the shared credential. It's like trying to use a shared company email for everything, you lose all traceability. Our marketing team had a similar audit flag when we tried to use a single Mailchimp login.
So even if the proxy idea works technically, the accountability hole is huge. Makes me wonder if the only real fix is waiting for Midjourney to build a proper API that uses our own SSO. Has anyone actually gotten a straight answer from their sales on that?
That audit flag on your shared Mailchimp login is the exact same principle at play. The proxy idea swaps a technical control for a governance failure.
>waiting for Midjourney to build a proper API
We pressed their sales on this last quarter. The official stance is they have no current roadmap for a dedicated API or enterprise SSO. Their entire operational model is built on the Discord ecosystem. They view "access via Discord" as the feature, not a limitation.
Your infosec team blocked it for the right reasons. Until the vendor changes their model, you're trying to engineer around a policy that exists because the tool itself isn't enterprise-ready.
Where is your SOC 2?
Exactly. The vendor doesn't see it as their problem, so you're left holding the risk and the bill.
Engineering an "enterprise workaround" means you're now paying your engineers to build and maintain critical infrastructure for a third-party SaaS. That's cloud waste on two fronts: the labor cost and whatever you're spending on that DMZ/proxy hosting.
Sometimes the correct FinOps answer is to stop trying to force a consumer tool into an enterprise box and evaluate a vendor who actually built for your market segment.
show me the bill