Is it possible to run headless Firefox in AWS Lightsail container and control it using Selenium from a Windows Server instance?

Other Questions Headless Browser
1

Hi everyone! I’m looking to set up a headless Firefox browser within a Lightsail container and control it remotely via Selenium from my Windows Server instance on Lightsail.

My objective is to launch browser sessions inside containers and automate them through the Windows server, but I’m facing multiple issues trying to get the Firefox container to work.

Each time I deploy my image, I encounter bizarre error messages about virtualization being disabled or needing Hyper-V support — which is confusing since I can’t access BIOS settings or enable Hyper-V on Lightsail.

I’ve tried several Dockerfile configurations and Firefox base images, but my containers either fail to start or crash upon launch. Below are two of the Dockerfiles I’ve experimented with that didn’t work:

FROM selenium/standalone-firefox:latest
CMD ["firefox", "--headless", "--no-sandbox", "--disable-gpu", "--marionette-host=0.0.0.0", "--marionette-port=2828"]

And another:

FROM ubuntu:20.04
RUN apt-get update && apt-get install -y \
    firefox \
    xvfb \
    wget \
    ca-certificates \
    fonts-dejavu-core \
    libasound2 \
    libgtk-3-0 \
    libx11-xcb1
EXPOSE 2828
CMD ["firefox", "--headless", "--marionette-host=0.0.0.0", "--marionette-port=2828"]

Both setups seem unreliable. I’m wondering if this setup even works on Lightsail or if I need to explore other AWS services for browser automation tasks? Any thoughts or advice would be greatly appreciated!

2

I’ve been running headless browsers on Lightsail containers for months now and those Hyper-V errors usually indicate resource constraints rather than actual virtualization issues. The problem with your second Dockerfile is missing the gecko driver setup - Firefox needs geckodriver to accept remote connections properly. Instead of fighting with custom configurations, I’d recommend using the official selenium hub/node architecture. Deploy selenium/hub container and selenium/node-firefox separately, then connect your Windows server to the hub endpoint. This approach isolates the browser processes and handles the networking much more reliably than trying to expose marionette directly. Also make sure your container has at least 1GB RAM allocated or Firefox will crash silently during startup.

3

yeah i had similar headaches with firefox containers on lightsail. try using the selenium/standalone-firefox image but skip the custom CMD - just use the default startup. then connect via remote webdriver on port 4444 instead of marionette directly. worked for me after tons of failed attempts with custom configs.

4

Running headless Firefox on Lightsail containers is definitely achievable, but your approach needs some adjustments. The virtualization errors you’re seeing are misleading - they’re actually related to container security contexts rather than actual hypervisor issues. I encountered this exact problem last year and solved it by adding the --disable-dev-shm-usage and --no-first-run flags to your Firefox command. More importantly, you need to run the container with --cap-add=SYS_ADMIN or use --security-opt seccomp=unconfined when deploying. Your first Dockerfile using selenium/standalone-firefox is the right direction, but remove the custom CMD entirely and let it use the default selenium grid setup. Then connect from your Windows server using RemoteWebDriver pointing to http://container-ip:4444/wd/hub instead of trying to use marionette protocol directly. This eliminates most of the networking headaches and provides better error handling.