Consulting on HIPAA compliant T3 based application
I am an AWS Solutions Architect and web developer looking to setup HIPAA HIPAA-compliant infrastructure to host a T3 application in AWS.
Vercel is out due to not offering a BAA.
Amplify is out because my database is in a private subnet and I can specify what VPC the lambdas are in
I am looking into SST or running on ECS.
I am willing to pay for a few hours of consulting with someone who has gone down this road.
I am using:
- NextJS
- trpc
- Prisma
- RDS Aurora (Postgres)
- Clerk
Anyone who has been down this road want to make a few bucks by saving me some time?
Thanks.
16 Replies
clerk is hippa compliant?
or your just inherintly not sending any hippa data to clerk
It's advertised for their enterprise tier
ah right
Intentionally not sending any PHI to clerk
I was at CCF for a while as an application dev but we had inhouse serverse which were defacto hippa compliant since they lived on prem
the easiest path for us was throwing everything into docker containers and putting it in a vm on one of the onprem servers
and just using a docker compose file to manage the images
Thank you for responding. I am considering building a docker image in a GitHub Actions runner and deploying it to ECS, possibly using aws copilot. Weirdest issue with that is having to build a docker image for dev, test and production. The Clerk public token is needed at build time so I can not build one docker image for all of my environments.
as in you have 3 different clerk environments?
how is the clerk token used during build time? could you just use a dummy token during build time and a real one during runtime
Two for now, the application will run in three different AWS accounts. dev/stage/prod. I two Clerk environments, one for dev/stage the other for prod.
On my list to dive deeper in to, but it has something to do with next build pregenerating pages that need the token.
im suspecting that it doesnt actually need the token
unless your trying to pre-generate user pages based on some query to the clerk client
in which case your just going to have to live with have 3 different builds
It is prerendering by default.
try giving it a dummy key
I can work with the three builds, I would prefer to use the same image artifact for all environments, but not the worse thing.
id have to see the code but id be very suprised if you actually need the clerk key set during build time
and im aware i cannot see the code since its most certianly under confidentiality lmao
I will give that a shot, thanks. All routes are secured behind clerk so I am not sure the prerendering is helping with anything.
okay so
let me try and explain this a different way
When the application is being built, since the application is using clerk in some capacity, its instantiating the clerk client with something like
new ClerkClient(env.CLERK_KEY) this is not verbatim code, just pseudo code. Point is, some value has to be in env.CLERK_KEY or whatever the environment variable is. Any page inside of clerk authentication is automatically switched to force-dynamic in terms of re validation / generation, so you are almost certainly not actually calling any clerk api during build time, unless there is some page that is displaying your total user count, or something like that, outside of your clerk auth wrapper. If this is the case, and you are not actually using the clerk client during build time, you can try giving it a dummy environment variable during build time (or, you could give it any one of the 3 clerk environment real keys in case it complains with a dummy key) and then provide the real key during runtime.Awesome, I appreciate your insight and will test with a dummy key.