Browser-Based Persistent Chrome VM on Cloud
Budget: $750 – $1,500 USD
Project: Browser-Based Persistent Chrome VM on AWS (ECS + EFS + noVNC)
I am looking for Staff or Staff+ level developer for this project. It is going to be a complex 1 pager web app. I will provide you with the basic screen design but here is the basic idea:
⸻⸻⸻⸻⸻
High Level Details:
⸻⸻⸻⸻⸻
• User logs in
• Click a button and logs into VM in browser (no password should be required for the user, user will already be authenticated before this)
• On the VM, Chrome should already be pre installed and open up.
• The installed chrome should have a specific extension installed (I will provide the code for this)
• The browser should automatically navigate to YouTube.
• User should not be able to control or click on the remote screen yet.
• Once we are here on Youtube page, we show a button to the user "Take Control & Sign In". User now should be able to Signin to Youtube.
• Once the user has signed in, we should popup another button which says "Give Control Back"
• We should now end the session.
• When user reopens session → user should still be logged in
Additionally:
• The extension installed will scroll the page and make a few API calls to the backend.
⸻⸻⸻⸻⸻
Overview
⸻⸻⸻⸻⸻
We are building a browser-accessible Linux desktop (VM-like experience) that runs Chromium inside a cloud environment, streamed to the user via the browser (noVNC).
⸻⸻⸻⸻⸻
Key requirement:
⸻⸻⸻⸻⸻
Users must remain logged into websites (Google/YouTube/etc.) across sessions by persisting the Chrome profile on AWS EFS, while compute remains ephemeral.
This is similar in spirit to systems like Manus / remote browser agents, but purpose-built and security-first.
⸻⸻⸻⸻⸻
Core Requirements (Must Have):
⸻⸻⸻⸻⸻
1. AWS Infrastructure
• VPC with public + private subnets
• ECS on EC2 (not Fargate)
• Application Load Balancer (TLS via ACM)
• NAT Gateway for stable egress
• EFS (encrypted) with per-user isolation
• DynamoDB for session registry + locking
• Cognito (or equivalent JWT verification)
2. Remote Desktop Stack
• Linux desktop environment (Xvfb or Xorg + Openbox/Xfce)
• Chromium browser with a extention pre-installed
• VNC + noVNC (WebSocket-based)
• Browser access via HTTPS only (no exposed VNC ports)
3. Persistent Chrome Login State
• Chrome launched with --user-data-dir pointing to user-specific EFS directory
• User logs into Google/YouTube once → remains logged in across sessions
• Enforce one active session per user to avoid profile corruption
• Ability to reset/wipe Chrome profile per user
4. Chrome Extension (Scraping)
• A specific Chrome extension must be pre-installed
• Extension should:
• Be force-loaded or policy-installed
• Persist across sessions
• Work with the persisted Chrome profile
•Extension may be unpacked or managed via policy (developer choice, explain tradeoffs)
5. Session Management
• Backend service to:
• Create sessions
• Launch ECS tasks
• Route user → correct container
• WebSocket gateway / proxy layer:
• Authenticates user (JWT)
• Proxies noVNC WebSocket traffic to correct ECS task
• Idle timeout + forced cleanup
• DynamoDB-backed session + lock table with TTLs
⸻⸻⸻⸻⸻
Security Requirements
⸻⸻⸻⸻⸻
• No direct exposure of ECS task ports
• All access via ALB + authenticated gateway
• EFS encrypted at rest (KMS)
• Strict IAM (principle of least privilege)
• Per-user filesystem isolation (no shared profiles)
• Stable outbound IP (single NAT EIP) to reduce Google re-auth prompts
⸻⸻⸻⸻⸻
Deliverables
⸻⸻⸻⸻⸻
0. Code
• All the code related to the project
• Clear README explaining the code base
1. Infrastructure
• Terraform or CloudFormation (preferred: Terraform)
• Clear README explaining architecture
2. Container Image
• Dockerfile(s) for session runner
• Includes desktop, Chromium, noVNC, extension
3. Backend Services
• Session creation + teardown
• WebSocket gateway / proxy
4. Documentation
• Architecture diagram
• Session flow
• Security model
• Cost assumptions
5. Demo
• User logs in
• Opens VM in browser
• Logs into YouTube
• Ends session
• Reopens session → still logged in
⸻⸻⸻⸻⸻
Nice to Have (Not Required)
⸻⸻⸻⸻⸻
• NICE DCV instead of noVNC (if justified)
• Per-user EFS Access Points
• Metrics + CloudWatch dashboards
• Session recording (optional)
⸻⸻⸻⸻⸻
Required Experience:
⸻⸻⸻⸻⸻
Please apply only if you have:
• Strong AWS experience (ECS, ALB, IAM, EFS, DynamoDB)
• Experience with remote desktop / browser automation / VNC / noVNC
• Comfort with WebSockets and reverse proxies
• Security-first mindset
• If you believe this can be done and hosted outside of AWS with a better/easier/cheaper infra, I would love to learn and open to taking that direction if it makes sense.
⸻
In Your Proposal, Include
1. Similar systems you’ve built (remote desktop, browser isolation, automation)
2. Your recommended architecture (brief)
3. How you’d install and persist the Chrome extension
4. Expected timeline (MVP vs hardened)
5. Major risks you see and how you’d mitigate them
I am looking for Staff or Staff+ level developer for this project. It is going to be a complex 1 pager web app. I will provide you with the basic screen design but here is the basic idea:
⸻⸻⸻⸻⸻
High Level Details:
⸻⸻⸻⸻⸻
• User logs in
• Click a button and logs into VM in browser (no password should be required for the user, user will already be authenticated before this)
• On the VM, Chrome should already be pre installed and open up.
• The installed chrome should have a specific extension installed (I will provide the code for this)
• The browser should automatically navigate to YouTube.
• User should not be able to control or click on the remote screen yet.
• Once we are here on Youtube page, we show a button to the user "Take Control & Sign In". User now should be able to Signin to Youtube.
• Once the user has signed in, we should popup another button which says "Give Control Back"
• We should now end the session.
• When user reopens session → user should still be logged in
Additionally:
• The extension installed will scroll the page and make a few API calls to the backend.
⸻⸻⸻⸻⸻
Overview
⸻⸻⸻⸻⸻
We are building a browser-accessible Linux desktop (VM-like experience) that runs Chromium inside a cloud environment, streamed to the user via the browser (noVNC).
⸻⸻⸻⸻⸻
Key requirement:
⸻⸻⸻⸻⸻
Users must remain logged into websites (Google/YouTube/etc.) across sessions by persisting the Chrome profile on AWS EFS, while compute remains ephemeral.
This is similar in spirit to systems like Manus / remote browser agents, but purpose-built and security-first.
⸻⸻⸻⸻⸻
Core Requirements (Must Have):
⸻⸻⸻⸻⸻
1. AWS Infrastructure
• VPC with public + private subnets
• ECS on EC2 (not Fargate)
• Application Load Balancer (TLS via ACM)
• NAT Gateway for stable egress
• EFS (encrypted) with per-user isolation
• DynamoDB for session registry + locking
• Cognito (or equivalent JWT verification)
2. Remote Desktop Stack
• Linux desktop environment (Xvfb or Xorg + Openbox/Xfce)
• Chromium browser with a extention pre-installed
• VNC + noVNC (WebSocket-based)
• Browser access via HTTPS only (no exposed VNC ports)
3. Persistent Chrome Login State
• Chrome launched with --user-data-dir pointing to user-specific EFS directory
• User logs into Google/YouTube once → remains logged in across sessions
• Enforce one active session per user to avoid profile corruption
• Ability to reset/wipe Chrome profile per user
4. Chrome Extension (Scraping)
• A specific Chrome extension must be pre-installed
• Extension should:
• Be force-loaded or policy-installed
• Persist across sessions
• Work with the persisted Chrome profile
•Extension may be unpacked or managed via policy (developer choice, explain tradeoffs)
5. Session Management
• Backend service to:
• Create sessions
• Launch ECS tasks
• Route user → correct container
• WebSocket gateway / proxy layer:
• Authenticates user (JWT)
• Proxies noVNC WebSocket traffic to correct ECS task
• Idle timeout + forced cleanup
• DynamoDB-backed session + lock table with TTLs
⸻⸻⸻⸻⸻
Security Requirements
⸻⸻⸻⸻⸻
• No direct exposure of ECS task ports
• All access via ALB + authenticated gateway
• EFS encrypted at rest (KMS)
• Strict IAM (principle of least privilege)
• Per-user filesystem isolation (no shared profiles)
• Stable outbound IP (single NAT EIP) to reduce Google re-auth prompts
⸻⸻⸻⸻⸻
Deliverables
⸻⸻⸻⸻⸻
0. Code
• All the code related to the project
• Clear README explaining the code base
1. Infrastructure
• Terraform or CloudFormation (preferred: Terraform)
• Clear README explaining architecture
2. Container Image
• Dockerfile(s) for session runner
• Includes desktop, Chromium, noVNC, extension
3. Backend Services
• Session creation + teardown
• WebSocket gateway / proxy
4. Documentation
• Architecture diagram
• Session flow
• Security model
• Cost assumptions
5. Demo
• User logs in
• Opens VM in browser
• Logs into YouTube
• Ends session
• Reopens session → still logged in
⸻⸻⸻⸻⸻
Nice to Have (Not Required)
⸻⸻⸻⸻⸻
• NICE DCV instead of noVNC (if justified)
• Per-user EFS Access Points
• Metrics + CloudWatch dashboards
• Session recording (optional)
⸻⸻⸻⸻⸻
Required Experience:
⸻⸻⸻⸻⸻
Please apply only if you have:
• Strong AWS experience (ECS, ALB, IAM, EFS, DynamoDB)
• Experience with remote desktop / browser automation / VNC / noVNC
• Comfort with WebSockets and reverse proxies
• Security-first mindset
• If you believe this can be done and hosted outside of AWS with a better/easier/cheaper infra, I would love to learn and open to taking that direction if it makes sense.
⸻
In Your Proposal, Include
1. Similar systems you’ve built (remote desktop, browser isolation, automation)
2. Your recommended architecture (brief)
3. How you’d install and persist the Chrome extension
4. Expected timeline (MVP vs hardened)
5. Major risks you see and how you’d mitigate them
Related categories:
Linux
Docker
Virtual Machines
Web Development
Security
Cloud Security
Microservices
Chromium
Web Application
Containerization