AWS Builder Center

Before You Share Your Portfolio: Five Checks for Your First AWS Deployment

Learn how to take your portfolio beyond localhost with AWS Amplify Hosting, and explore five practical checks before sharing it—from deployment files and page routes to testing and costs.

Aspiring Software Engineer and Free Lancer
A beginner’s guide to moving a student website beyond localhost with AWS Amplify Hosting.
Imagine finishing your portfolio website the night before an internship application.
The layout looks clean. Your project cards work. The navigation takes you to the right sections. You copy the address from your browser and send it to a friend:
“a local development address”
Then comes the reply: “It doesn’t open.”
The website works. The address is the problem.
For someone learning web development, this is a useful introduction to deployment. Writing HTML, CSS, and JavaScript gives you a website you can develop locally. Hosting makes that website accessible to other people.
Before choosing hosting settings or sharing a link, it helps to answer five practical questions.

1. Does the link point to your computer?

localhost refers to the device making the request.
When you open “a local development address” on your laptop, your browser connects to a service running on your laptop. When your friend opens that same address, their browser looks for a service on their own device.
Sending the address does not send your website.
A development server can sometimes be configured for access from other devices on a local network. That is useful for testing, but it is different from publishing a portfolio at a public web address.
For a shareable portfolio, you need a hosting service that can receive visitors’ requests and serve your website.
AWS Amplify Hosting is one option. It supports static websites and popular web frameworks, and deploys applications to an AWS content delivery network—a distributed system for delivering content to visitors.

2. What does your website actually need to run?

Consider two student projects.
The first is a portfolio containing an introduction, project descriptions, images, and links. The second is a placement portal where students sign in, submit applications, and retrieve saved information.
Their hosting needs are different.
A static website can still be interactive. Buttons, animations, and browser-based search do not automatically require a backend.
However, uploading a page containing a contact form does not create a service that saves or emails the message. That functionality must be connected separately.
For a first deployment, a portfolio with public information and no backend dependency keeps the scope manageable.

3. Are you deploying the files visitors need?

A project’s source folder and its deployable output are not always the same thing.
For a plain HTML website, the deployable files may be your HTML pages, stylesheet, JavaScript, and images.
For a frontend project that uses a build tool, you generally run the production build and deploy its output. The output directory depends on the tool and your configuration.
Think of it as preparing a submission: your working folder contains everything used to create the project, while the final package contains what the hosting service needs.
Amplify Hosting supports manual deployment without connecting a Git repository. Its documented workflow lets you upload a ZIP archive containing your build output. Manual deployments do not support server-side rendered applications.
For a simple static portfolio, the documented steps are:
  1. Open the AWS Amplify console and choose Create new app.
  2. Select Deploy without Git.
  3. Enter an app name and branch name.
  4. Choose Drag and drop, then upload your ZIP archive.
  5. Choose Save and deploy.
One packaging detail matters: ZIP the contents of the output directory, rather than enclosing them inside an extra parent directory. AWS documents this distinction because the wrong structure can prevent the website root from being initialized correctly.
For a plain HTML portfolio, check that index.html is at the archive’s root and that the files it references are included.

4. Does the website work when someone enters through a different page?

Opening the homepage is only the first test.
Suppose a React portfolio uses client-side routes such as /projects. Clicking a navigation button may work because the application is already loaded and its router handles the change.
Now imagine a recruiter opening /projects directly, or refreshing that page.
The hosting service receives a request for that path before the browser application can handle it. Depending on your hosting configuration, the result may be a missing-page error.
Amplify supports rewrites that can serve an application’s index.html while preserving the requested address, allowing a client-side router to handle the route. Use AWS’s documented SPA rewrite guidance when your application needs this behavior. A traditional website with separate HTML pages may need a different configuration.
Before sharing your portfolio, test:
  • The homepage.
  • A project page opened directly.
  • A browser refresh on that project page.
  • Images, navigation links, and downloads.
  • Any feature that depends on an API.
That last check is easy to overlook. If frontend code still calls “a backend running on your laptop” , a visitor’s browser will try to contact the visitor’s own device. Deploying the frontend does not move your local backend with it.

5. Can someone use it without your development setup?

Your laptop is a forgiving test environment. It already has your files, tools, and local services.
A visitor has none of those.
Open the deployed website on a phone using mobile data. This helps reveal dependencies on your development environment or local network. An incognito window can also reveal assumptions about previously saved browser state.
Ask someone to complete three tasks:
  1. Find your strongest project.
  2. Open its repository or demonstration.
  3. Find a way to contact you.
Watch where they hesitate. A working deployment can still have broken links, unreadable text, or a button whose purpose is unclear.
Also review what you publish. Files delivered to a browser can be inspected, so private credentials should not be included in frontend code or deployed assets. A portfolio ZIP should contain the public website, not your entire working directory.
Finally, check hosting costs. Amplify uses usage-based pricing, and free usage eligibility depends on the applicable offer and account conditions. Review the current pricing page rather than assuming a small portfolio will always cost nothing.

A small first project

You do not need a database, login system, or complicated architecture to begin learning deployment.
Start with a single-page portfolio containing:
  • A short introduction.
  • Two project descriptions.
  • Repository links.
  • A contact link.
Prepare the deployable files, publish them through Amplify Hosting, and test the resulting website from another device.
Once that works, you can explore a Git-connected workflow. Amplify Hosting supports continuous deployment, which lets you build a repeatable process for publishing changes from a connected repository.
The first useful milestone is a simple one: someone else can open your link and use your website without needing your laptop.
That turns deployment from an unfamiliar cloud concept into something you can understand, test, and improve.

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article