The telemetry service depends on this now. I had to move it into
invokeFunction and use accessor.get otherwise getLogger on the service
was undefined.
I also had to move some the extension management service because it
depends on the moved telemetry service. I moved a few other services as
well to better match VS Code (sharedProcessMain.ts).
I swapped some this.services.get with accessor.get since that seems to
be the correct method although for these other services either method
seems to work.
I removed this under the impression the default was to allow it anywhere
but that's not the case. Since the service worker was already registered
in my browser I never got the error during testing.
Also move our memory default to the beginning of NODE_OPTIONS so it can
be overidden. The version of the flag with dashes seems to be the more
correct one now so use that instead of underscores.
Related: #2113.
I think having them combined and relying on if statements was getting
confusing especially if we want to add additional messages with
different payloads (which will soon be the case).
Turns out that while Typescript can't infer the callback return type
from it, Typescript can do the opposite and infer it from the callback
return type.
Unfortunately we can't use node-mocks-http to test a express.Router
that has async routes. See https://github.com/howardabrams/node-mocks-http/issues/225
router will just return undefined if the executing handler is async and
so the test will have no way to wait for it to complete. Thus, we have
to use supertest which starts an actual HTTP server in the background
and uses a HTTP client to send requests.
This is mostly so we don't have to do any wacky patching but it also
makes it so we don't have to keep checking if the request is a web
socket request every time we add middleware.
This way the connection can be initiated by either side. It looks like
sometimes the initial message from the client is lost (it never makes it
into the onControlMessage callback) but I'm still not sure why or if
that is preventable.
Also added a timeout on the server end to clean things up in case the
client never responds.
Now we add a subject alt name, set extendedKeyUsage and use the
correct certificate extension.
The above allow it to be properly trusted by iOS.
See https://support.apple.com/en-us/HT210176
*.cert isn't a real extension for certificates, *.crt is correct
for it to be recognized by e.g. keychain or when importing as a profile
into iOS.
Updates #1566
I've been able to successfully connect from my iPad Pro now to my
code-server instance with a self signed certificate! Next commit
will be docs.
If do not update the UID within the passwd database to match whatever
uid the container is being ran as, then sudo will not work when renaming
the user to match $DOCKER_USER as it will complain about the current
user being non-existent.
Removing them just for peace of mind even though they seem to get
filtered out later. This line is meant to only add remote extensions
that aren't capable of running in the browser. If they are
browser-capable they don't need to run in our shimmed Node environment.
This makes the fetch work independently of the worker's origin which is
no longer the same as the main thread (the main problem is the inability
to send cookies without setting SameSite to None).
This matches with the html in the VS Code repo and also fixes a problem
with the worker which loads HTML using data: and then can't load any
scripts because 'self' doesn't work.
- The .js build files are no longer committed so they're gone.
- ParsedArgs and EnvironmentService are now NativeParsedArgs and
NativeEnvironmentService.
- Interface for environment service was moved.
- getPathFromAmdModule was deprecated.
Otherwise it outputs when trying to open a file in an existing instance
externally. Externally there isn't an environment variable to branch on
to skip this line so instead output it with the other info lines in the
child process.
- Immediately create ipcMain so it doesn't have to be a function which I
think feels cleaner.
- Move exit handling to a separate function to compensate (otherwise
the VS Code CLI for example won't be able to exit on its own).
- New isChild prop that is clearer than checking for parentPid (IMO).
- Skip all the checks that aren't necessary for the child process (like
--help, --version, etc).
- Since we check if we're the child in entry go ahead and move the
wrap code into entry as well since that's basically what it does.
- Use a single catch at the end of the entry.
- Split out the VS Code CLI and existing instance code into separate
functions.
We only want to use an old version for glibc which the centos:7
image takes care of.
The old version of git used in debian:8 was causing problems
with the uid/gid passthrough with no user in passwd.
We do not try renaming $HOME anymore as there is no good way
to do it.
We also only try to convert if the user hasn't been changed.
Finally I added usage to the docker docs in install.md
Closes#2056
VS Code has a short delay before writing storage (probably to queue up
rapid changes). In the web version of VS Code this happens on the client
which means if the page is reloaded before the delay expires the write
never happens.
Storage updates are already promises so this simply returns the promise
returned by the delayer so it won't resolve until the write actually
happens.
Fixes#2021.
Add initial support for opening files / folders in running code-server instance.
Current limitations:
- unable to open a file in a new window, only folders
- unable to use addMode feature
- others...
We need the handler to be recognized as a PWA but we can just let the
original offline browser message show instead of our own message.
See #1925 and #1979.
tsc doesn't check if the output exists when incremental is true.
i.e if I delete the out directory, but keep the tsbuildinfo and
try to rebuild, nothing happens cause it thinks everything is
up to date I guess...
With this change, yarn clean will now remove the tsbuildinfo correctly
so things work as expected.
Otherwise the build keeps failing for me as tsc won't compile anymore.
Not sure why things work on CI/for asher but I don't think this will
cause any additional issues.
It can still be used to check for updates but will not apply them.
For now also remove the update check loop in VS Code since it's
currently unused (update check is hardcoded off right now) and won't
work anyway since it also applies the update which now won't work. In
the future we should integrate the check into the browser update
service.
- Instead we now use CentOS 7 for the static build to guarantee
that we only depend on libc v2.17
- For macOS we now pull in a static node binary and bundle that instead.
This release fixes bugs introduced with the release of v3.3.0
- We've reverted to VS Code 1.45.1 due to bugs in 1.46 #1667
- Accessing code-server from a web browser on Windows has been fixed#1642
- Search in project has been fixed#1665
- The glibc requirement on static releases has been lowered to v2.19 #1656
Pass the user data dir to the browser environment service then derive
all the paths we can based off that path like the global storage path
which the vim extension uses to store history (otherwise it gets stored
in the working directory from when code-server was spawned).
Arguably the better solution is to use the userdata scheme but that
won't work because the vim extension ignores the VS Code API.
Fixes#1551.
See #1532 for more context.
- Errored JSON requests will get back the error in JSON instead of using
the status text. This seems better to me because it seems more correct
to utilize the response body over hijacking the status text. The
caller is expecting JSON anyway. Worst of all I never actually set the
status text like I thought I did so it wasn't working to begin with.
- Allow the update error to propagate for JSON update requests. It was
caught to show the error inline instead of an error page when using
the update page but for JSON requests it meant there was no error and
no error code so it looked like it succeeded.
- Make errors for failed requests to GitHub less incomprehensible.
Previously they would just be the code which is no context at all.
The raw value is now passed back to VS Code so it can do the parsing
with its own URI class rather than trying to parse using Node's url
module first since that has no guarantee of working the same way. It
also lets us keep the vscode-remote bit internal to VS Code.
Removed the logic that keeps trying paths until it finds a valid one
because it seems confusing to open a path and silently get some other
path instead of an error for the one you tried to open. Now it'll just
use exactly what you specified or fail trying.
Fixes#1488. The problem here was that url.parse was encoding the spaces
then the validation failed looking for a literal %20.
- Add type to HTTP options.
- Fix certificate message always saying it was generated.
- Dedent output not directly related to the HTTP server.
- Remove unnecessary comma.
In Google cloud shell the host header is 127.0.0.1:8080 instead of the
actual URL. This is what we write out to the HTML so VS Code can pick it
up. However cloud shell rewrites this string when found in the HTML
before serving it so it becomes https://8080-[...].appspot.com,
resulting in an extra unexpected https:// in the
URI (vscode-remote://https://8080[...]). The resulting malformed URI
causes the extension host to exit.
- Fixes#1471
- Fixes#1468
- Fixes#1440 (most likely).
This will make it work regardless of what the current URL happens to be.
Also move the telemetry setting into the options since we might as well
make use of it seeing as how we have to parse it for the base path
anyway.
By design the disable-telemetry flag does not affect extension
telemetry, only the setting does, so disabling the setting when the flag
is set should cause extensions to also stop sending telemetry.
Fixes#1116.
It still won't work behind a base path, but if you're using a reverse
proxy you can just redirect to HTTPS yourself. And should probably
handle TLS termination there too.
For sockets I just needed to add back the proxy call.
I temporarily removed this during the refactor so it needed to be added
back. This time I bundled it with the nbin loader code since it's all
related (will also make it easier to remove).
- Add VS Code icon
- Trim dashboard to just display dedicated VS Code section
- Version was getting unset during build
- Add back nbin shim which I temporarily took out earlier
- Update tests for log level env var changes
Might fix#1181, although not for the reasons I initially
thought (because the URLs are resolved from the manifest path, not the
path of the current page). This should ensure that the URLs used by the
manifest are always correct regardless of the manifest's path.
When using a query parameter without a scheme, the scheme defaults to
`file`. This results in the files in the explorer being technically
different from the file picker files because they are file:// instead of
vscode-remote://, causing the same file to open twice and causing
numerous issues.
Normally the file explorer wouldn't even load at all in this case but we
provide a file service for file:// URLs as a failsafe for certain files
that wouldn't load correctly in the past. These files load fine now
using the vscode-remote scheme, so I'm also removing that service.
Related: #1351.
Fixes#1294.
https://github.com/cdr/code-server/issues/1188
Fixes issue with permissions mounting in directories in the container. Folders are generated by root causing issues when the container user "coder" wants to create sub-folders. This fix solves it, at least on Crostini (ChromeOS)
Fixes issues with unexpected characters breaking things when setting the
cookie (like semicolons).
This change as-is does not affect the security of code-server
itself (we've just replaced the static password with a static hash) but
if we were to add a salt in the future it would let us invalidate keys
by rehashing with a new salt which could be handy.
If you visit /login/ instead of /login the cookie will be set at /login
instead of / which means the cookie can't be read at the root. It will
redirect to the login page which *can* read the cookie at /login and
redirect back resulting in an infinite loop.
The previous solution relied on setting the cookie at / (any invalid
value works) which then overrode the login page cookie since
parseCookies only kept a single value. So the login page would see the
same cookie the root was seeing and not redirect back. However, that
behavior depends on the cookies being in the right order which I'm not
sure is guaranteed.
This new method tests all available cookies and always sets the cookie
so the root path will be able to read it in case the login page is
seeing a cookie the root can't.
It also goes a step further and explicitly sets the path on the cookie
which fixes the case where there is a permanent misconfiguration
redirecting /login to /login/. Otherwise the cookie would continually be
set on /login only and you'd have another loop. It also means you only
need to delete one cookie to log out.
Lastly add some properties to make the cookies a bit more secure.
It doesn't show in the explorer anymore so there's no point. Also remove
the local scheme transform which is no longer required with the latest
client-side extension implementation.
Instead of doing a separate redundant build. The main problem was that
the files weren't being cached. There is probably a better way of
solving this but this seems to be the simplest for now.
This matches how the rest of the build is organized but also hopefully
solves an issue where the VS Code directory is empty because we try to
cache it directly and Travis might be creating it.
Also too the opportunity to rewrite the build script since there was a
change in the build steps (mainly how the product JSON is inserted) and
to get the build changes out of the patch. It also no longer relies on
external caching (we'll want to do this within CI instead).
- Copy old icon back into repository
- Update path to icon from manifest file
- Add link metadata tag for iOS PWA icon to workbench.html
- Add link metadata tag for iOS PWA icon to login page
* [README] add Requirements section
This is based user feedback and testing. This may expand if need be
Signed-off-by: Ayane Satomi <chinodesuuu@gmail.com>
* [README] raised the bar a bit more
Apparently we were targeting GLIBC 2.17
Signed-off-by: Ayane Satomi <chinodesuuu@gmail.com>
- Don't error if trying to tag and the tag already exists.
- Add the build arguments to the Docker build.
- Set an environment variable for the Docker build rather than using
- the username because the username always exists (on master anyway).
* made spacing for travis yaml consistent in file
* cleaned up .travis.yml and moved some code into a script
* checking if i can get travis to build this
* travis
* fixed an if statement
* fixed travis.yml file
* replaced my name with codercom
There's no way to actually know if those clients have gone away, so it
seems it might be better to base it on whether the user has connected
again with new clients to determine if the old clients are now invalid.
It gets the web URL for the file yet uses the file service to load it,
so having a sub-path causes it not to be found on disk (the sub-path
obviously only means anything for the web server and isn't on disk).
This removes the potential for a bad build because the native Node
modules currently can only be built on the target system, so specifying
a target for something other than the system your are building on will
not work.
- Implement the localization service.
- Use the proper build process which generates the require JSON files.
- Implement getting the locale and language configuration.
- Don't use "any" for the API type.
- Remove everything from the Coder API that can eventually be done
through the VS Code API.
- Move the event emission to our own client to minimize patching.
This means that you have to turn on features now instead of disabling
them like auth and https.
In addition:
- Allow multiple options for auth (only password for now).
- Combine the install docs since they had many commonalities and
- generally simplified them (hopefully not too much).
- Move all example configs into docs/examples.
When `isAuthed()` is called and the password cookie is not what we
expected, the failed login attempt is logged with the provided password,
remote address and user agent.
To allow for logging failed attempts with a reverse proxy, the
`--trust-proxy` argument has been added to trust the `X-Forwarded-For`
header. This implementation of an `X-Forwarded-For` parser uses the last
value in the list, therefore only trusting the nearest proxy.
I run code-server behind an authenticating Kubernetes Ingress which sets a cookie after a successful login is performed. Since this cookie is not set when fetching the manifest, the fetch fails and gets redirected to the authentication page, breaking code-server completely.
See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link
This is to match how the other binaries are built. Also made some
changes to make the Docker containers clean up for when you are running
this locally.
Since there is no other way to enable hidden files, it seems better to
enable it by default otherwise there are some folders/files you simply
can never open from the dialog.
Run [VS Code](https://github.com/Microsoft/vscode) on any machine anywhere and access it in the browser.
`code-server` is [VS Code](https://github.com/Microsoft/vscode) running on a remote server, accessible through the browser.

Try it out:
```bash
docker run -it -p 127.0.0.1:8443:8443 -v "${PWD}:/home/coder/project" codercom/code-server --allow-http --no-auth
```
## Highlights
- Code on your Chromebook, tablet, and laptop with a consistent dev environment.
-If you have a Windows or Mac workstation, more easily develop for Linux.
-Take advantage of large cloud servers to speed up tests, compilations, downloads, and more.
- Preserve battery life when you're on the go.
- All intensive computation runs on your server.
- You're no longer running excess instances of Chrome.

- Code on any device with a consistent development environment
-Use cloud servers to speed up tests, compilations, downloads, and more
-Preserve battery life when you're on the go; all intensive tasks run on your server
## Getting Started
### Run over SSH
There are two ways to get started:
Use [sshcode](https://github.com/codercom/sshcode) for a simple setup.
1. Using the [install script](./install.sh), which automates most of the process. The script uses the system package manager (if possible)
2. Manually installing code-server; see [Installation](./doc/install.md) for instructions applicable to most use cases
### Docker
If you choose to use the install script, you can preview what occurs during the install process:
See docker oneliner mentioned above. Dockerfile is at [/Dockerfile](/Dockerfile).
```bash
curl -fsSL https://code-server.dev/install.sh | sh -s -- --dry-run
```
### Binaries
To install, run:
1. [Download a binary](https://github.com/cdr/code-server/releases) (Linux and OS X supported. Windows coming soon)
2. Start the binary with the project directory as the first argument
```bash
curl -fsSL https://code-server.dev/install.sh | sh
```
```
code-server <initial directory to open>
```
> You will be prompted to enter the password shown in the CLI
`code-server` should now be running at https://localhost:8443.
When done, the install script prints out instructions for running and starting code-server.
> code-server uses a self-signed SSL certificate that may prompt your browser to ask you some additional questions before you proceed. Please [read here](doc/self-hosted/index.md) for more information.
We also have an in-depth [setup and configuration](./doc/guide.md) guide.
For detailed instructions and troubleshooting, see the [self-hosted quick start guide](doc/self-hosted/index.md).
### Alpha Program 🐣
Quickstart guides for [Google Cloud](doc/admin/install/google_cloud.md), [AWS](doc/admin/install/aws.md), and [DigitalOcean](doc/admin/install/digitalocean.md).
We're working on a cloud platform that makes deploying and managing code-server easier.
Consider updating to the latest version and running code-server with our experimental flag `--link` if you don't want to worry about
How to [secure your setup](/doc/security/ssl.md).
- TLS
- Authentication
- Port Forwarding
## Development
```bash
$ code-server --link
Proxying code-server to Coder Cloud, you can access your IDE at https://valmar-jon.cdr.co
```
### Known Issues
## FAQ
- Creating custom VS Code extensions and debugging them doesn't work.
See [./doc/FAQ.md](./doc/FAQ.md).
### Future
- **Stay up to date!** Get notified about new releases of code-server.

- Windows support.
- Electron and Chrome OS applications to bridge the gap between local<->remote.
- Run VS Code unit tests against our builds to ensure features work as expected.
## Want to help?
### Extensions
See [CONTRIBUTING](./doc/CONTRIBUTING.md) for details.
At the moment we can't use the official VSCode Marketplace. We've created a custom extension marketplace focused around open-sourced extensions. However, if you have access to the `.vsix` file, you can manually install the extension.
## Hiring
## Telemetry
We ([@cdr](https://github.com/cdr)) are looking for engineers to help [maintain
code-server](https://jobs.lever.co/coder/e40becde-2cbd-4885-9029-e5c7b0a734b8), innovate on open source, and streamline dev workflows.
Use the `--disable-telemetry` flag or set `DISABLE_TELEMETRY=true` to disable tracking ENTIRELY.
Our main office is in Austin, Texas. Remote is ok as long as
you're in North America or Europe.
We use data collected to improve code-server.
Please get in [touch](mailto:jobs@coder.com) with your resume/GitHub if interested.
## Contributing
## For Organizations
Development guides are coming soon.
## License
[MIT](LICENSE)
## Enterprise
Visit [our enterprise page](https://coder.com/enterprise) for more information about our enterprise offering.
## Commercialization
If you would like to commercialize code-server, please contact contact@coder.com.
Visit [our website](https://coder.com) for more information about remote development for your organization or enterprise.
1. Microsoft/vscode version 1.47.0 (https://github.com/Microsoft/vscode)
%% Microsoft/vscode NOTICES AND INFORMATION BEGIN HERE
=========================================
MIT License
Copyright (c) 2015 - present Microsoft Corporation
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
This directory contains scripts used for code-server's continuous integration infrastructure.
Some of these scripts contain more detailed documentation and options
in header comments.
Any file or directory in this subdirectory should be documented here.
- [./ci/lib.sh](./lib.sh)
- Contains code duplicated across these scripts.
## Publishing a release
Make sure you have `$GITHUB_TOKEN` set and [hub](https://github.com/github/hub) installed.
1. Update the version of code-server and make a PR.
1. Update in `package.json`
2. Update in [./doc/install.md](../doc/install.md)
3. Update in [./ci/helm-chart/README.md](../ci/helm-chart/README.md)
- Remember to update the chart version as well on top of appVersion in `Chart.yaml`.
2. GitHub actions will generate the `npm-package`, `release-packages` and `release-images` artifacts.
1. You do not have to wait for these.
3. Run `yarn release:github-draft` to create a GitHub draft release from the template with
the updated version.
1. Summarize the major changes in the release notes and link to the relevant issues.
4. Wait for the artifacts in step 2 to build.
5. Run `yarn release:github-assets` to download the `release-packages` artifact.
- It will upload them to the draft release.
6. Run some basic sanity tests on one of the released packages.
- Especially make sure the terminal works fine.
7. Make sure the github release tag is the commit with the artifacts. This is a bug in
`hub` where uploading assets in step 5 will break the tag.
8. Publish the release and merge the PR.
1. CI will automatically grab the artifacts and then:
1. Publish the NPM package from `npm-package`.
2. Publish the Docker Hub image from `release-images`.
9. Update the AUR package.
- Instructions on updating the AUR package are at [cdr/code-server-aur](https://github.com/cdr/code-server-aur).
10. Wait for the npm package to be published.
11. Update the homebrew package.
- Send a pull request to [homebrew-core](https://github.com/Homebrew/homebrew-core) with the URL in the [formula](https://github.com/Homebrew/homebrew-core/blob/master/Formula/code-server.rb) updated.
## dev
This directory contains scripts used for the development of code-server.
- [./ci/dev/image](./dev/image)
- See [./doc/CONTRIBUTING.md](../doc/CONTRIBUTING.md) for docs on the development container.
- Have [nfpm](https://github.com/goreleaser/nfpm) (which is used to build `.deb` and `.rpm` packages and [jq](https://stedolan.github.io/jq/) (used to build code-server releases) installed
The [CI container](../ci/images/debian8/Dockerfile) is a useful reference for all
of the dependencies code-server uses.
## Development Workflow
```shell
yarn
yarn vscode
yarn watch
# Visit http://localhost:8080 once the build is completed.
```
To develop inside an isolated Docker container:
```shell
./ci/dev/image/run.sh yarn
./ci/dev/image/run.sh yarn vscode
./ci/dev/image/run.sh yarn watch
```
`yarn watch` will live reload changes to the source.
If you introduce changes to the patch and you've previously built, you
must (1) manually reset VS Code and (2) run `yarn vscode:patch`.
## Build
You can build using:
```shell
./ci/dev/image/run.sh ./ci/steps/release.sh
```
Run your build with:
```shell
cd release
yarn --production
# Runs the built JavaScript with Node.
node .
```
Build the release packages (make sure that you run `./ci/steps/release.sh` first):
This tutorial shows you how to deploy `code-server` on an EC2 AWS instance.
If you're just starting out, we recommend [installing code-server locally](../../self-hosted/index.md). It takes only a few minutes and lets you try out all of the features.
---
## Deploy to EC2
### Use the AWS wizard
- Click **Launch Instance** from your [EC2 dashboard](https://console.aws.amazon.com/ec2/v2/home).
- Select the Ubuntu Server 16.04 LTS (HVM), SSD Volume Type (`ami-0f9cf087c1f27d9b1)` at this time of writing)
- Select an appropriate instance size (we recommend t2.medium/large, depending on team size and number of repositories/languages enabled), then **Next: Configure Instance Details**
- Select **Next: ...** until you get to the **Configure Security Group** page, then add the default **HTTP** rule (port range "80", source "0.0.0.0/0, ::/0")
> Rules with source of 0.0.0.0/0 allow all IP addresses to access your instance. We recommend setting [security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html?icmpid=docs_ec2_console) to allow access from known IP addresses only.
- Click **Launch**
- You will be prompted to create a key pair
> A key pair consists of a public key that AWS stores, and a private key file that you store. Together, they allow you to connect to your instance securely. For Windows AMIs, the private key file is required to obtain the password used to log into your instance. For Linux AMIs, the private key file allows you to securely SSH into your instance.
- From the dropdown choose "create a new pair", give the key pair a name
- Click **Download Key Pair**
> This is necessary before you proceed. A `.pem` file will be downloaded. make sure you store is in a safe location because it can't be retrieved once we move on.
- Finally, click **Launch Instances**
---
### SSH Into EC2 Instance
- First head to your [EC2 dashboard](https://console.aws.amazon.com/ec2/v2/home) and choose instances from the left panel
- In the description of your EC2 instance copy the public DNS (iPv4) address using the copy to clipboard button
- Open a terminal on your computer and use the following command to SSH into your EC2 instance
```
ssh -i "path/to/your/keypair.pem" ubuntu@(paste the public DNS here)
- Replace {version} in the following command with the version found on the releases page and run it (or just copy the download URL from the releases page):
- Extract the downloaded tar.gz file with this command, for example:
```
tar -xvzf code-server-{version}-linux-x64.tar.gz
```
- Navigate to extracted directory with this command:
```
cd code-server-{version}-linux-x64
```
- If you run into any permission errors, make the binary executable by running:
```
chmod +x code-server
```
> To ensure the connection between you and your server is encrypted view our guide on [securing your setup](../../security/ssl.md)
- Finally, run
```
sudo ./code-server -p 80
```
- When you visit the public IP for your AWS instance, you will be greeted with this page. Code-server is using a self-signed SSL certificate for easy setup. To proceed to the IDE, click **"Advanced"**<img src ="../../assets/chrome_warning.png">
- Then click **"proceed anyway"**<img src="../../assets/chrome_confirm.png">
> For instructions on how to keep the server running after you end your SSH session please checkout [how to use systemd](https://www.linode.com/docs/quick-answers/linux/start-service-at-boot/) to start linux based services if they are killed
> The `-p 80` flag is necessary in order to make the IDE accessible from the public IP of your instance (also available from the description in the instances page.
---
> NOTE: If you get stuck or need help, [file an issue](https://github.com/cdr/code-server/issues/new?&title=Improve+self-hosted+quickstart+guide), [tweet (@coderhq)](https://twitter.com/coderhq) or [email](mailto:support@coder.com?subject=Self-hosted%20quickstart%20guide).
This tutorial shows you how to deploy `code-server` to a single node running on DigitalOcean.
If you're just starting out, we recommend [installing code-server locally](../../self-hosted/index.md). It takes only a few minutes and lets you try out all of the features.
---
## Use the "Create Droplets" wizard
[Open your DigitalOcean dashboard](https://cloud.digitalocean.com/droplets/new) to create a new droplet
- **Choose an image -** Select the **Distributions** tab and then choose Ubuntu
- **Choose a size -** We recommend at least 4GB RAM and 2 CPU, more depending on team size and number of repositories/languages enabled.
- Launch your instance
- Open a terminal on your computer and SSH into your instance
> example: ssh root@203.0.113.0
- Once in the SSH session, visit code-server [releases page](https://github.com/cdr/code-server/releases/) and copy the link to the download for the latest linux release
- Replace {version} in the following command with the version found on the releases page and run it (or just copy the download URL from the releases page):
- Extract the downloaded tar.gz file with this command, for example:
```
tar -xvzf code-server-{version}-linux-x64.tar.gz
```
- Navigate to extracted directory with this command:
```
cd code-server-{version}-linux-x64
```
- If you run into any permission errors when attempting to run the binary:
```
chmod +x code-server
```
> To ensure the connection between you and your server is encrypted view our guide on [securing your setup](../../security/ssl.md)
- Finally start the code-server
```
sudo ./code-server -p 80
```
> For instructions on how to keep the server running after you end your SSH session please checkout [how to use systemd](https://www.linode.com/docs/quick-answers/linux/start-service-at-boot/) to start linux based services if they are killed
- When you visit the public IP for your Digital Ocean instance, you will be greeted with this page. Code-server is using a self-signed SSL certificate for easy setup. To proceed to the IDE, click **"Advanced"**<img src ="../../assets/chrome_warning.png">
- Then click **"proceed anyway"**<img src="../../assets/chrome_confirm.png">
---
> NOTE: If you get stuck or need help, [file an issue](https://github.com/cdr/code-server/issues/new?&title=Improve+self-hosted+quickstart+guide), [tweet (@coderhq)](https://twitter.com/coderhq) or [email](mailto:support@coder.com?subject=Self-hosted%20quickstart%20guide).
This tutorial shows you how to deploy `code-server` to a single node running on Google Cloud.
If you're just starting out, we recommend [installing code-server locally](../../self-hosted/index.md). It takes only a few minutes and lets you try out all of the features.
---
## Deploy to Google Cloud VM
> Pre-requisite: Please [set up Google Cloud SDK](https://cloud.google.com/sdk/docs/) on your local machine
- [Open your Google Cloud console](https://console.cloud.google.com/compute/instances) to create a new VM instance and click **Create Instance**
- Choose an appropriate machine type (we recommend 2 vCPU and 7.5 GB RAM, more depending on team size and number of repositories/languages enabled)
- Choose Ubuntu 16.04 LTS as your boot disk
- Check the boxes for **Allow HTTP traffic** and **Allow HTTPS traffic** in the **Firewall** section
- Create your VM, and **take note** of its public IP address.
- Copy the link to download the latest Linux binary from our [releases page](https://github.com/cdr/code-server/releases)
- Replace {version} in the following command with the version found on the releases page and run it (or just copy the download URL from the releases page):
- Extract the downloaded tar.gz file with this command, for example:
```
tar -xvzf code-server-{version}-linux-x64.tar.gz
```
- Navigate to extracted directory with this command:
```
cd code-server-{version}-linux-x64
```
- Make the binary executable if you run into any errors regarding permission:
```
chmod +x code-server
```
> To ensure the connection between you and your server is encrypted view our guide on [securing your setup](../security/ssl.md)
- Start the code-server
```
sudo ./code-server -p 80
```
> For instructions on how to keep the server running after you end your SSH session please checkout [how to use systemd](https://www.linode.com/docs/quick-answers/linux/start-service-at-boot/) to start linux based services if they are killed
- Access code-server from the public IP of your Google Cloud instance we noted earlier in your browser.
> example: 32.32.32.234
- You will be greeted with this page. Code-server is using a self-signed SSL certificate for easy setup. To proceed to the IDE, click **"Advanced"**<img src ="../../assets/chrome_warning.png">
- Then click **"proceed anyway"**<img src="../../assets/chrome_confirm.png">
---
> NOTE: If you get stuck or need help, [file an issue](https://github.com/cdr/code-server/issues/new?&title=Improve+self-hosted+quickstart+guide), [tweet (@coderhq)](https://twitter.com/coderhq) or [email](mailto:support@coder.com?subject=Self-hosted%20quickstart%20guide).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.